Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2010

1 participants
31 discussions

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

21 Mar '10

[00:10:20] <CIA-92> ffmpeg: stefano * r22602 /trunk/doc/ffserver-doc.texi: [00:10:20] <CIA-92> ffmpeg: List the FFserver specific options under a "Main options" section, to [00:10:20] <CIA-92> ffmpeg: distinguish them from the generic common options. [00:53:02] <CIA-92> ffmpeg: michael * r22603 /trunk/libavcodec/error_resilience.c: Error concealment of h264 with multiple references. [01:03:32] <CIA-92> ffmpeg: mru * r22604 /trunk/ffmpeg.c: 10l: fix build without termios.h [09:19:34] <DonDiego> moin [09:19:44] <kshishkov> god morgon [09:20:05] <DonDiego> can anybody confirm libfaad2 being around twice as fast as ffmpeg when decoding AAC SBR? [09:20:08] <DonDiego> peloverde: you? [09:20:51] <ohsix> does faad not ignore sbr? [09:22:28] <kshishkov> DonDiego: don't you have samples for that? [09:24:51] <_av500_> faad does sbr iirc [09:25:29] <kshishkov> it has [09:29:09] <elenril> ffaac is ~2x faster than faad for me [09:29:47] <kshishkov> probably SBR decoding is not optimized well enough [09:30:47] * elenril wonders why do he get DECAUDIO: AUDIO: 24000 Hz, 2 ch, s16le, 128.0 kbit/16.67% (ratio: 16000->96000) with ffaac [09:31:05] <elenril> and DECAUDIO: AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000) with faad [09:32:12] <kshishkov> because it does not report doubled sampling rate with SBR [09:32:30] <pJok> god morgon kshishkov :) [09:32:32] <elenril> oh [09:32:37] <kshishkov> goda morgnar [09:33:17] <kshishkov> yet what does mplayer -benchmark -ac ffaac -ao null thatfile says at the end? [09:36:21] <elenril> hmm, with ffaac audio plays at half speed [09:36:38] <kshishkov> try with ffplay [09:36:47] <kshishkov> (aka future MPlayer) [09:37:04] <elenril> yesh, ffplay sounds almost normally [09:37:17] <elenril> but still somewhat slower [09:37:30] <elenril> probably because ffplay fails at vfr or something [09:38:00] * elenril wonders why does it fail with mplayer [09:40:15] <elenril> DonDiego: anyway except for that ffaac is much faster [09:48:18] * elenril wonders how to force a decoder with ffmpeg [09:48:38] <Dark_Shikari> -vcodec X -i whatever [09:48:43] <Dark_Shikari> or -acodec X -i whatever [09:49:43] <elenril> thanks [09:50:48] <elenril> yeah, same results with ffmpeg - ffaac >> faad [09:50:53] <elenril> all hail peloverde [09:51:44] <kshishkov> indeed [10:01:07] <Kovensky> <+elenril> all hail peloverde <-- did it get committed? :o [10:02:20] <elenril> ofc [10:02:27] <kshishkov> yes, otherwise there'd be no talk about SBR support in ffaac [10:02:29] <elenril> a few week ago [10:02:33] <elenril> +s [10:03:16] <Kovensky> lol [10:04:33] <Kovensky> <@verm__> jfs: i remembered the reason why i designed the mru interface the way i did <-- itc: an interface to mru [10:09:19] <DonDiego> kshishkov: -ao nulll will not work [10:09:25] <DonDiego> it plays at normal speed [10:09:52] * elenril used -ao pcm:fast:file=/dev/null [10:10:10] <kshishkov> whatever [10:11:44] <DonDiego> elenril: i don't get half speed, sample? [10:14:35] <DonDiego> http://samples.ffmpeg.org/V-codecs/h264/cathedral-beta2-400extra-crop-avc.m… [10:14:39] <DonDiego> take this sample [10:14:46] <DonDiego> mplayer dumps audio faster with faad [10:18:02] <elenril> oh, happens only with internal mkv demuxer [10:18:11] <elenril> works fine with lavf [10:33:11] <elenril> DonDiego: http://pastebin.ca/1846509 [11:23:40] <DonDiego> elenril: you should add -quiet [11:24:29] <DonDiego> http://pastebin.ca/1846539 [11:24:35] <DonDiego> updated with my numbers alongside it.. [11:27:25] <DonDiego> maybe it's because i'm running on my trusty old K6-III [11:27:35] <DonDiego> which lacks some mmx2/sse asm? [11:27:55] <elenril> yeah, probably [11:28:03] <elenril> i'm on core duo [11:28:27] <DonDiego> i'll never see the day when i can get rid of libfaad :-( [11:28:32] * DonDiego cries his eyes out [11:29:32] <Dark_Shikari> DonDiego: simple solution [11:29:33] <Dark_Shikari> get rid of the k6-3 [11:29:38] <Dark_Shikari> then nobody will ever have to care about such shit again [11:34:33] <saste> DonDiego: where is the nut-container.org web site stuff stored? [11:34:47] <saste> I'm browsing http://nut-container.org/ [11:35:06] <saste> the link to the spec points to a websvn page which is non-existing [11:36:12] <saste> I also tried to look for the websvn of mplayer on the Mplayer site with no luck [11:39:36] <saste> there is a mplayer git repo somewhere? [11:40:01] <elenril> no unless you count uau's fork [11:41:00] <DonDiego> saste: you can check out the svn repository [11:41:06] <saste> I was asking because that would allow to do like in http://git.ffmpeg.org/ [11:41:18] <DonDiego> complain to attila and mans [11:41:32] <DonDiego> i did not take down the web frontend to svn [11:41:36] <saste> DonDiego: I know but we should fix the dangling link in nut-container.org [11:41:44] <DonDiego> and i'm still annoyed it's no longer available [11:42:03] <saste> if we can't point to the websvn page then we should directly put the static page somewhere [11:42:07] <jai> saste: this was reported multiple times, noone cares [11:42:12] <DonDiego> Dark_Shikari: i don't have money to replace my perfectly working computer [11:42:46] <DonDiego> saste: if you care, upload a copy of the spec to the website directly [11:43:03] <saste> DonDiego: yes I'll try to do that [11:43:35] <Dark_Shikari> DonDiego: then we can start a donation fund [11:43:36] <Dark_Shikari> for you and michael [11:43:39] <saste> that's why I was asking where I can find the nut-container web site stuff ;-) [11:43:43] <Dark_Shikari> for $200 we can get you something modern [11:44:18] <DonDiego> IIRC: svn://svn.ffmpeg.org/nut [11:44:28] <jai> saste: you could maintain a clone of the repo on one of the git hosting services and link to that [11:44:38] <saste> DonDiego: thanks [11:44:42] <jai> i dont think websvn is coming back in the near future [11:44:58] <saste> jai: yes that's possible just I still don't have experience with that [11:44:59] <DonDiego> Dark_Shikari: i kinda like my old computer [11:45:14] <DonDiego> and i think there is value in somebody running an old machine [11:45:15] <saste> jaj: also I'd like to see ffmpeg migrate to git soon or later [11:45:28] <DonDiego> not everybody lives in the 1st world, you know.. [11:45:31] <Dark_Shikari> DonDiego: people running old machines gets us stuff like ffmpeg's asm [11:45:39] <Dark_Shikari> where most of the asm is ancient mmx [11:45:41] <Dark_Shikari> i.e. swscale [11:45:46] <Dark_Shikari> because devs can't be bothered to get new computers [11:45:46] <jai> saste: ah, well dont hold your breath :) [11:45:46] <DonDiego> no [11:46:06] <DonDiego> that's because the asm was written for the machines available back then [11:46:13] <Dark_Shikari> no, that's because michael still has a pentium dual [11:46:16] <Dark_Shikari> >_> [11:46:37] <DonDiego> no, mn hasn't written asm for libswscale in many years [11:46:40] <Dark_Shikari> exactly [11:46:45] <Dark_Shikari> because it's good enough for his computer [11:46:50] <DonDiego> i think mans has an old computer lying around [11:46:54] <Dark_Shikari> but if he got a new computer, he would go improve it [11:46:55] <DonDiego> donate that to michael [11:47:00] <Dark_Shikari> I can say from experience that I do not write much asm for anything that doesn't work on my computer [11:47:05] <Dark_Shikari> or even things that do, but won't run on it [11:47:10] <Dark_Shikari> e.g. I almost never optimize for phenom [11:47:15] <Dark_Shikari> because I don't have any phenom boxes, not even on ssh [11:47:26] <Dark_Shikari> pengvado is the same [11:47:30] <DonDiego> that's why i say we need devs with old computers [11:47:35] <Dark_Shikari> and with a sample size of 2, I generalize to everyone [11:47:49] <Dark_Shikari> "having an old computer" != "not having a new computer" [11:48:05] <DonDiego> the stuff you actually use counts [11:48:12] <DonDiego> i can compile on faster boxes nowadays [11:48:19] <Dark_Shikari> no, it's what you have [11:48:22] <DonDiego> though admittedly i don't always do it [11:48:24] <Dark_Shikari> I optimized for nehalem for a year before I got one [11:48:27] <Dark_Shikari> because I had one on ssh [11:48:37] <Dark_Shikari> I optimized for a penryn for over a year and I have yet to ever get one [11:48:58] <Dark_Shikari> anyways ffmpeg devs should not be slowed down by ancient hardware [11:49:02] <Dark_Shikari> and "3rd world" is no excuse [11:49:10] <DonDiego> and i make sure stuff continues to run decently on old x86 boxes [11:49:11] <jai> well, patches are welcome [11:49:19] <Dark_Shikari> I have a friend who lives in estonia, their median income is 10x worse than the US [11:49:20] <jai> so people with newer cpus could write the asm [11:49:23] <Dark_Shikari> and their internet is faster than us. [11:49:44] <DonDiego> that's besides the point [11:50:00] <DonDiego> the USA lives in the network dark ages [11:50:19] <Dark_Shikari> furthermore, someone who spends a large portion of his life on a computer can afford to spend $200 on a new one ;) [11:50:23] <DonDiego> still there are many many people that cannot afford modern computers [11:50:32] <DonDiego> they use their old stuff or get them second hand [11:50:43] <Dark_Shikari> "second-hand computers"are now athlon 64s and athlon xps [11:50:50] <Dark_Shikari> and you can find them in dumpsters [11:50:52] <DonDiego> where you live, yes [11:51:04] <Dark_Shikari> Then getting one to where you live is a shipping fee away. [11:51:22] <Dark_Shikari> We had an entire cart full of pentium 4s at this year's dorm auction [11:51:25] <Dark_Shikari> none even got bid on [11:51:27] <Dark_Shikari> nobody even wanted them [11:51:29] <Dark_Shikari> not even for $1 [11:51:42] <Dark_Shikari> they weren't even worth chopping up for spare parts. [11:51:43] <DonDiego> that processor sucks.. [11:51:55] <Dark_Shikari> having a k6-3 is just not excusable. [11:52:13] <DonDiego> anyway, do you have a point to make? [11:52:29] <Dark_Shikari> ffmpeg devs should be treated better. [11:52:32] <Dark_Shikari> that's my point. [11:52:39] <Dark_Shikari> and they should treat themselves better too. [11:53:00] <Dark_Shikari> you know that if you asked for money for an upgrade, you'd get it. [11:53:02] <pross-au> shucks, my main comps are P4 (dothan) and G4 [11:53:15] <Dark_Shikari> still much better than a K6-3 :> [11:53:29] <DonDiego> i'll think about it [11:53:29] <pross-au> My K6-2 PSU died. [11:53:45] <DonDiego> i just upgraded my disks in any case ;) [11:54:01] <DonDiego> and now i have around 100GB total capacity.. [11:54:02] <pross-au> Otherwise its operational :D [11:54:09] <jai> well, gsoc is on and DonDiego could get enough for a nehalem :) [11:54:20] <jai> he did say once that he wanted to participate [11:54:28] <Dark_Shikari> 100gb? lol [11:54:43] <DonDiego> i might try to get a used g5, they look interesting [11:54:45] <Dark_Shikari> I don't even have enough usb slots for all my hard disks, I could send you a 500gb [11:54:46] <pross-au> Cloud computing means that you dont need a powerful desktop comp [11:55:08] <DonDiego> ok, i need to get some work done [11:55:09] <DonDiego> bbl [11:59:46] * kshishkov is glad he skipped all that discussion [12:03:32] <Dark_Shikari> blegh, I've spent the past hour reading papers on intra mode decision in h264 [12:03:35] <twnqx> <Dark_Shikari> having a k6-3 is just not excusable. <- where should i send my spare athlon xp 1800+? [12:03:36] <Dark_Shikari> it's staggering how bad these things are [12:03:55] <Dark_Shikari> twnqx: michael or diego? =p but seriously, I'd want to make sure michael has a nehalem [12:07:45] <KotH> osoi-yo! [12:07:51] <KotH> janneg: fogir is idle ;) [12:08:07] <kshishkov> Dark_Shikari: make somebody send him a notebook with it [12:08:36] * KotH would volunteer to bring it to him personaly [12:09:00] <kshishkov> indeed [12:09:20] <twnqx> why a nehalem? [12:09:27] <twnqx> isn't that some P4? [12:09:38] <Dark_Shikari> i7 [12:10:46] <twnqx> that one i'll keep. [12:13:55] <Compn> Dark_Shikari : write something up on x264 project page 'in an effort to speed up all projects using ffmpeg, we would like to donate i7's to all ffmpeg asm devels. please pony up some cash for this' [12:14:21] <twnqx> lol [12:16:36] <pross-au> Atoms [12:17:07] <pross-au> i3s [12:18:04] <kshishkov> pross-au: Atom was good for me and allowed compiling FFmpeg for BeagleBoard. Too bad its packaging was shite. Strewth! [12:18:09] <Compn> kshishkov : someone on -dev-eng just mentioned vp6 interlaced ... [12:18:23] <kshishkov> Compn: and? [12:18:51] <Compn> oops, i guess that is aurel's code [12:18:56] <Compn> nm [12:19:37] <pross-au> Just pointing out that not every intel owner is an i7 owner [12:20:24] * kshishkov has 80i186 [12:20:31] <saste> DonDiego: I need the nut specification pages published somewhere on the web so that I can create a link to them in nut/homepage/index.html [12:21:00] <saste> DonDiego: hopefully all the nut/docs dir should be accessible somewhere [12:22:32] <saste> DonDiego: there is no hurry i'll be away from my computer till tomorrow afternoon [12:27:00] <jai> well, thats why i said fork a copy onto guthub or sth :) [12:32:00] <saste> jai: well I'll explore that option i can't find a more lazy solution ;-) [12:45:17] <Dark_Shikari> hmm. some of these papers are actually pretty cool. an IP core for an intra analysis engine that takes 3.5 milliwatts for 1080p [12:48:07] <KotH> what papers? [12:48:18] <twnqx> D_S: what is actually done during ratecontrol lookahead, just calculate a metric for picture complexity? [12:48:23] <Dark_Shikari> was just randomely browsing shit on google scholar [12:48:29] <Dark_Shikari> twnqx: oh ho ho, quite a bit more complicated than that [12:48:32] <Dark_Shikari> frametype decision [12:48:34] <Dark_Shikari> macroblock-tree [12:49:04] <Dark_Shikari> which includes up to (--bframes + 3) motion searches per frame [12:49:14] <Dark_Shikari> and by motion search I mean a search for all blocks in that frame [12:49:16] <Dark_Shikari> and intra analysis [12:49:21] <twnqx> wow, so already the motion vector search is there? [12:49:24] <Dark_Shikari> yes [12:49:27] <Dark_Shikari> it's not the main search [12:49:28] <twnqx> i see [12:49:30] <Dark_Shikari> it's a simplified search [12:49:34] <Dark_Shikari> downscaled by 2 in each direction [12:49:54] <Dark_Shikari> no multiref, no partitions, SAD only, final destination [12:50:23] <twnqx> so only refined later. makes sense [12:50:35] <Dark_Shikari> it isn't refined [12:50:36] <Dark_Shikari> it's thrown away [12:50:42] <Dark_Shikari> the lookahead data is only used for lookahead [12:50:53] <KotH> hmm.. can someone tell me what "folk psychology" vs "folk physics" is? [12:50:53] <Dark_Shikari> the only thing re-used is that a few of the MVs get used as predictors later. [12:51:49] <kshishkov> KotH: system of beliefs not based on facts covering different areas of "knowledge" [12:53:00] <KotH> hmm.. and what has that to do with child development? ^^' [12:53:41] <kshishkov> read Pratchett - "lies to children" is a good way to explaining them something in completely wrong way [12:57:36] <twnqx> what the FUCK [12:57:42] <twnqx> i went to seagate.com [12:57:52] <kshishkov> BTW, does this mean you've finally decided to take responsibility and raise one of your children? [12:57:53] <twnqx> and the thing... selected my language as ru-ru :S [12:57:54] <KotH> kshishkov: the wiki entry? [12:58:13] <KotH> kshishkov: nah.. just reading something on authism and genetics [12:59:35] <kshishkov> twnqx: http://xkcd.com/713/ [13:07:37] <twnqx> heh [13:16:26] * KotH wonders whether there are any differential studies of brain activity between vegetarians and carnivors [13:17:52] <superdump> ? [13:17:54] <superdump> why? [13:18:06] <kshishkov> for me it setlearn biology [13:18:15] <kshishkov> s/.*set// [13:18:56] <kshishkov> food (among other things) defines man [13:19:20] <Dark_Shikari> so stop drinking so much soda. [13:20:06] <kshishkov> it's water or tea for me [13:20:13] <Dark_Shikari> good. [13:20:37] <kshishkov> it's mostly because everything else is bad [13:21:46] <KotH> superdump: oh.. just because glutamat is one of the most important neurotransmitters, which is a protein. so if vegetarians have less intake of proteins, they'll have less glutamat which should result in an impared brain function [13:21:58] <Dark_Shikari> since when do vegetarians have less protein? [13:22:15] <Dark_Shikari> I'd be more worried about less fat and too much carbs [13:22:16] <Dark_Shikari> but protein is easy [13:22:19] <Dark_Shikari> just eat lots of nuts and soy [13:22:21] <KotH> ok.. depends on your definition of vegetarian :) [13:22:33] <Dark_Shikari> and also, "vegan" vs "vegeterian" [13:22:35] <Dark_Shikari> vegetarians eat cheese [13:22:36] <kshishkov> KotH: not mentioning unique aminoacids of animal origin [13:22:44] <Dark_Shikari> vegans don't [13:22:47] <superdump> i eat lots of cheese [13:22:54] <superdump> and beans [13:23:10] <superdump> and more recently nuts [13:23:26] <kshishkov> you should've tried eating nuts earlier [13:23:41] * elenril thinks nut needs more attention [13:23:42] * elenril runs [13:23:53] <Dark_Shikari> cashews, btw, are amazing [13:24:09] <Dark_Shikari> like 70% fat, 35% protein, -5% carbs [13:24:16] * KotH curses wikipedia [13:24:40] <kshishkov> Dark_Shikari: nothing beats macadamia [13:24:45] <KotH> i haven't even finished the first page of the paper i wanted to read... but several wp articles instead ^^' [13:25:11] <Dark_Shikari> oh wow. that's pretty impressive [13:25:22] <Dark_Shikari> 74g fat, 9.2g protein, 7.9g carbs, per 100g. [13:33:49] * justlooking_ always thought that if god wanted you to be a "vegan" or "vegeterian" then he would have not invented Appendicitis, and he/she would have made everyone green and be able to use Photosynthesis as a backup. [13:36:47] * kshishkov lives in a region where most holy food is considered treif [13:37:50] <CIA-30> ffmpeg: jbr * r22605 /trunk/ (12 files in 3 dirs): [13:37:50] <CIA-30> ffmpeg: Add VorbisComment writing to FLAC files. [13:37:50] <CIA-30> ffmpeg: Patch by James Darnley <james darnley at gmail>. [13:37:52] <kshishkov> so IMNSHO just eat what you want [13:38:02] <elenril> \o/ [13:39:37] <superdump> kshishkov: what's treif [13:39:40] <superdump> ? [13:39:49] <kshishkov> non-kosher [13:39:59] <kshishkov> in Judaism [13:40:10] <superdump> heh [13:40:13] <CIA-30> ffmpeg: jbr * r22606 /trunk/libavformat/ (Makefile oggenc.c): [13:40:13] <CIA-30> ffmpeg: Add VorbisComment writing to Ogg/FLAC and Ogg/Speex files. [13:40:13] <CIA-30> ffmpeg: Patch by James Darnley <james darnley at gmail> [13:40:54] <elenril> \o/ ^2 [13:41:32] * superdump always thought that people had the freedom to choose who they wanted to be and how they wanted to live so there wasn't any dictation that one must eat animals and as one doesn't need to, one can choose not to and be healthy [13:42:16] <kshishkov> superdump: exactly, but then came those vagens, Greenpeace activists and other loonies [13:42:19] <superdump> maybe eating animals was the simplest way for human kind to develop to the point where we could understand that [13:42:21] <kshishkov> *vegans [13:43:07] <kshishkov> it just quite effective food [13:43:30] <kshishkov> and happens in larger quantities too [13:43:37] <CIA-30> ffmpeg: jbr * r22607 /trunk/ (Changelog libavformat/avformat.h): [13:43:37] <CIA-30> ffmpeg: Add Changelog entry and bump lavf micro version for the addition of [13:43:37] <CIA-30> ffmpeg: VorbisComment writing for FLAC, Ogg/FLAC, and Ogg/Speex files. [13:45:39] <kshishkov> just like certain activists must not limit our choice of codecs to use to the family mantioned in last commit message [13:47:48] <J_Darnley> elenril: there you go, all applied now [13:48:06] <elenril> cool [13:48:46] <J_Darnley> Now I just need to sort out comments for ogg-vorbis files [13:49:26] <J_Darnley> I've got a very hacky patch that crashes when using libvorbis [13:49:29] <elenril> wait, metadata format is different for each codec? [13:49:50] <J_Darnley> Some what [13:49:56] <Kovensky> <+elenril> wait, metadata format is different for each codec? <-- surprised? [13:50:15] <J_Darnley> The problem is a combination of ogg and ffmpeg [13:50:48] <J_Darnley> _My_ problem is [13:51:41] <kshishkov> don't use ogg then ;) [13:52:11] <elenril> av500: what's up with writing asf chapters? [13:54:37] <DonDiego> kshishkov: btw, you were looking for something to RE, i have a suggestion: QDM2 [13:54:44] <DonDiego> it's not quite finished [13:54:54] <DonDiego> there is a mode that does not decode exactly [13:55:01] <DonDiego> there are noticeable artifacts [13:55:39] <DonDiego> the sound is somewhat metallic [13:55:41] <DonDiego> http://samples.ffmpeg.org/A-codecs/QDM2/reason_300.mov [13:55:52] <DonDiego> i think this is one of the samples that shows the artifacts [14:01:37] <BBB> hi spyfeng [14:01:46] <BBB> good work on the mms tree, I'll look at the state tomorrow [14:02:01] <BBB> spyfeng: if you're confident and it works, feel free to submit a first version for more general review already [14:02:03] <twnqx> http://img534.imageshack.us/img534/8765/bbbx.png that's what BBBs do to your comps :S [14:02:08] <BBB> it'd be good to get it up to speed [14:02:14] <DonDiego> http://a1852.g.akamai.net/5/1852/184/3e1e2226/1a1a1a25940a73d84b79ea5ed4026… [14:02:15] <spyfeng> hi BBB [14:02:35] <BBB> holy shit 700% cpu [14:02:42] <DonDiego> kshishkov: direct link to a failing sample [14:02:52] <BBB> DonDiego: farmsluts? [14:02:55] <BBB> suggestive.... [14:03:00] <spyfeng> I'll review it for myself and simply the code for serveral times :) [14:03:09] <BBB> spyfeng: that's a good idea also [14:03:17] <BBB> spyfeng: did you submit your soc proposal yet? [14:03:18] <kshishkov> DonDiego: I'll put it to box [14:03:19] <spyfeng> then submit it a first version asap [14:03:20] <BBB> or isn't it open? [14:03:25] <spyfeng> no [14:03:29] <BBB> oh [14:03:37] <BBB> oh I guess it opens monday [14:03:43] <spyfeng> it doesn't open yet. [14:04:21] <DonDiego> BBB: go watch the movie [14:04:37] <DonDiego> it's a very funny short about a guy who gets a link to some special pr0n at work [14:04:58] <DonDiego> his life takes a downward turn after that, very black humor :) [14:05:06] <DonDiego> kshishkov: put it to box? [14:05:23] <kshishkov> yep, "filed" [14:05:58] <DonDiego> are you interested in working on this? [14:06:07] <kshishkov> not particularly [14:06:26] <kshishkov> but I may work on it in future [14:08:03] <DonDiego> it would be appreciated [14:08:11] <DonDiego> those incomplete codecs are a PITA [14:08:16] <DonDiego> bbl [14:08:31] * kshishkov "maintains" another one - WMV3 [14:08:51] <DonDiego> yeah, but i guess qdm2 would be simpler to fix [14:09:03] <DonDiego> there's also qdmc waiting to be REed [14:10:28] <kshishkov> a lot of other stuff too [14:18:16] <BBB> spyfeng: at the top, MMSCSPacketType, SC_PACKET_.._TYPE, you can rename them all to SC_PKT_... (without TYPE) [14:18:19] <BBB> saves another couple of bytes [14:26:09] <twnqx> hm [14:26:35] <twnqx> i have 8 80mm fans, spinning at ~10krpm, next to me [14:26:59] <twnqx> rendering is noisy. [14:27:34] <twnqx> and power consumption jumped from 400W to 600W for this box :S [14:27:37] <kshishkov> and I thought that 3D Studio MAX 1.1 was a CPU/RAm-hungry beast [14:28:08] <kshishkov> that's more than total comsumption for all my boxes [14:28:43] <justlooking> perhaps yu should do some case modding and get more effective airflow so you can remove 6 of them... [14:28:58] <twnqx> mh.... no. [14:29:37] <twnqx> i don't mod my 2U server chassis :P [14:30:38] <twnqx> anyway, time to change rooms [14:30:41] <twnqx> football time \o/ [14:33:31] <KotH> .o0(it isnt summer yet, why is twnqx sitting in the server room?) [14:33:52] <twnqx> because i pulled my servers from the data center yesterday [14:33:55] <twnqx> to fix them. [14:34:02] <twnqx> gonna return them tomorrow [14:34:46] <twnqx> hm [14:34:53] <twnqx> actually, this i7 is not doing anywthing... [14:48:32] <janneg> KotH: the problem of manual scheduling [14:50:41] * janneg has not enough trust in the queue systems to run any of them over the internet [15:15:03] <justlooking> "trust in the queue systems" what systems ? and why not write your own if thats the case anyway? use something like this rebol script as you base for instance http://itmmetelko.com/blog/2009/07/03/rebols-actor-net-used-for-real-distri… http://musiclessonz.com/rebol_tutorial.html [15:15:55] <kshishkov> I don't like that language name. Reminds me of 60s horrors [15:16:58] <kshishkov> and syntax looks like tcl/tk [15:17:25] <justlooking> i dont like green eggs and ham, so im not going to try it.... [15:18:23] * kshishkov does not like virtually everything, so don't mind [15:23:20] <justlooking> well Carl Sassenrath was the Amiga lead OS dev so he knows a thing or two about small light productive codeing, try it if you like cross plafrom scripting perhaps, http://www.rebol.com/oneliners.html [15:23:49] <justlooking> platform [15:23:57] <kshishkov> we have _Perl_ [15:25:12] <mru> shell script and perl is all we need [15:25:37] <mru> shell script obviously including sed and awk [15:25:52] <kshishkov> can be replaced with Perl in case of trouble [15:28:51] <justlooking> you have a perl script for that BBB scheduling job ? and you can do it in a few pages of script and a 600Kbyte exe, so why doesnt janneg trust it then ?, [15:30:39] * BBB grmbls [15:38:40] <twnqx> lol [15:38:57] * twnqx pats the bunny [15:39:16] <twnqx> now stop eating my ram and CPUs :P [15:54:42] <kshishkov> twnqx: that's because you have them in abundance. My <= 1 GB RAM boxes are good to fend off any Blender [15:54:54] <twnqx> :P [16:04:23] <twnqx> <APTX> int i; [&]() { [&]() { i; }; }; - C++ almost like perl now :) [16:04:41] <twnqx> yey for lambda expressions in c++ :P [16:05:00] <kshishkov> we also have _Perl_ for that [16:05:17] <twnqx> but but... native! [16:05:25] <mru> wtf does that do? [16:05:59] <twnqx> what *will* it do, once the next spec is throug and implemented [16:06:06] * KotH thinks that perl is easier to understand [16:06:33] <mru> fine, wtf will that do? [16:06:35] <kshishkov> another reason to forget C++ [16:07:26] <twnqx> dunno. APTX says it does nothing, but it will be valid code :P [16:08:01] <kshishkov> of course [16:08:16] <kshishkov> and what if it was i++ inside? [16:08:41] <twnqx> i never understood lambda functions. [16:08:58] <kshishkov> but it's easy [16:10:22] <mru> in lisp a lambda function is simply an unnamed function typically passed as an argument to something expecting a function reference [16:10:35] <mru> and no, "reference" isn't correct lisp parlance [16:12:24] <kshishkov> Java took it further - you create whole unnamed class for single function as an argument [16:13:44] <mru> ugh, don't remind me [16:13:50] <mru> the syntax is horrible too [16:13:58] <kshishkov> of course [16:14:17] <kshishkov> "everything is an object except for atomic types" was a wonderful idea [16:19:47] <twnqx> janneg: are there actually scenes you can render with 6G ram? 10&12 need >6 each [16:35:03] <justlooking> <kshishkov> "everything is an object except for atomic types" was a wonderful idea < you like that object idea but wont even try rebol http://www.rebol.com/docs/core23/rebolcore-10.html "REBOL stands for relative expression based _object language_ ." http://www.rebol.com/what-rebol.html , twnqx i take it people didnt try setting up sliced rendering so you dont need all this ram in a single pc for the hard scenes then! [16:38:52] <kshishkov> justlooking: there was a thing invented lately called "sarcasm" [16:41:03] * justlooking cant find the US patent on that ;) Ohh "sarcasm" nm [16:49:31] <peloverde> DonDiego, ffaac is about 25% faster than faad for streams with SBR [16:49:35] <peloverde> for me [16:50:36] <kshishkov> peloverde: as we found out, it's slower for him since lavc does not have 3DNow! SIMD speedups for it [16:50:46] <peloverde> ahhh [16:50:57] <peloverde> I was going to say that it prbably is a little slow on non SSE systems [16:52:46] <CIA-30> ffmpeg: michael * r22608 /trunk/libavcodec/error_resilience.c: [16:52:46] <CIA-30> ffmpeg: Hotfix for regtest-error failure [16:52:46] <CIA-30> ffmpeg: a proper fix appears to require changing h263/mpeg2/motion est to index ref_index like [16:52:46] <CIA-30> ffmpeg: h264. Ill do this change and then revert this hotfix but it will take a bit time. [17:17:17] <siretart`> DonDiego: ping [17:23:52] <Kovensky> <@mru> the syntax is horrible too <-- new JButton().addActionListener(new ActionListener() { public void actionPerformed(ActionEvent evt) {} }); [17:24:01] <Kovensky> why do I still remember this D: [17:24:52] <DonDiego> siretart`: pong [17:25:32] <DonDiego> peloverde: my numbers indicate that that faad is about twice as fast as ffaac with sbr on non-sse systems :( [17:25:34] <mfg> is make test failing for anyone else? [17:25:37] <DonDiego> what's the exact reason? [17:25:42] <mfg> I just updated, and it fails on seek tests [17:26:16] <siretart`> DonDiego: hey there. what's the status? :-) [17:26:19] <mru> make test passes here [17:26:22] <mfg> hmmm [17:26:30] <DonDiego> siretart`: 0.5.2? 0.6? [17:26:31] <kshishkov> Kovensky: the same reason as I - it's so utter crap that you do it once and remember forever. Java GUI code sucks even more than plain Java [17:26:40] <kierank> java gui itself also sucks [17:26:45] <siretart`> DonDiego: 0.6. I didn't really start working on the remaining patches [17:26:47] <siretart`> for 0.6.2 [17:26:51] <siretart`> for 0.5.2 [17:26:59] <DonDiego> Yuvi: what's the status? :) [17:27:05] <peloverde> DonDiego, A new filterbank would help other than that I'd probably need to see some profiling data [17:27:14] <Kovensky> <@kshishkov> Kovensky: the same reason as I - it's so utter crap that you do it once and remember forever. Java GUI code sucks even more than plain Java <-- I guess [17:27:24] <DonDiego> peloverde: what do you mean by new filterbank? [17:27:42] <DonDiego> can i (easily) provide some profiling to you? [17:27:44] <Kovensky> Swing is also the only GUI toolkit where I can remember the basic classes and functions without needing a reference >_> [17:28:03] <peloverde> The SBR analysis/synthesis filterbank could probably be done better [17:28:29] <peloverde> as far as profiling goes, just make sure the top level functions in ff_sbr_apply() don't get inlined [17:29:33] <DonDiego> speak to me in layman's terms please, i think i've profiled once or twice in my life :) [17:29:47] <DonDiego> (running oprofile under guidance or similar) [17:32:41] <janneg> twnqx: probably half of all currently rendered frames are rendered with 6G or less [17:32:42] <peloverde> I don't know how to get oprofile to work either [17:32:57] <DonDiego> you have it running on your machine though? [17:33:22] <DonDiego> getting oprofile up and running should be doable [17:33:36] <DonDiego> if you later tell me what exactly you want/need profiled, i can do that [17:33:56] <peloverde> Nearly every oprofile guide I can find is about profiling the kernel itself [17:34:10] <janneg> twnqx: 05_throwing-0[3789] rendered without problems [17:34:10] <DonDiego> what do you use for profiling? [17:34:33] <peloverde> I use callgrind and verify with time [17:34:57] <DonDiego> callgrind_annotate callgrind_control [17:35:02] <DonDiego> i have these two in my path [17:41:13] <DonDiego> peloverde: what do you do exactly with callgrind and time? [17:41:51] <DonDiego> (there is no callgrind_* man page on my system) [17:42:30] <peloverde> valgrind --tool=callgrind ./ffmpeg_g -vn -i file.m4a -f null /dev/null [17:43:26] <DonDiego> i'll try that later, after a recompile, i need to get to do some work now.. [17:45:27] <peloverde> ok [17:45:32] <twnqx> janneg: http://img534.imageshack.us/img534/8765/bbbx.png maybe my blender is a bit more hungry than others... [17:48:34] <twnqx> then again... mem usage seems to be lower, with just 9G total [17:53:04] <peloverde> Why are japanese broadcasters broadcasting something that seems a lot like aac but isn't? [17:53:43] <mru> not aac at all? [17:53:46] <kierank> dunno, japanese tv is weird [17:54:11] <kierank> coreaac plays the actual program audio ok, but not the adverts and last time i tried ffmpeg did it the other way round [17:54:28] <peloverde> Well it doesn't conform to 14496-3 or 13818-7 so it's not AAC [17:54:42] <kierank> it's meant to be the latter [17:54:55] <kierank> but they could have modified it in their national specs [17:56:12] <peloverde> why not just follow the rules in the spec? [17:56:33] <peloverde> they are there to guarantee interoperability [17:57:10] <twnqx> they are afraid of streamrippers and reencoders [17:57:11] <janneg> but then everybody could play^Wsteal that precious intellectual property [17:57:29] <peloverde> I don't think it's obsfucation [17:57:34] <peloverde> I think it's a lazy muxer [17:58:23] <peloverde> It's the classic element instance tags are changing midstream issue [17:59:20] <janneg> twnqx: it's strange, I somehow suspect blender has some automatic memory usage tuneables or a lazy GC if there's no memory pressure [18:00:17] <superdump> peloverde: maybe we should add a 'treat element instance tags naively' mode? [18:00:34] <superdump> so that crap streams can be played in some form [18:00:50] <kierank> hmmm version.sh doesn't work in mingw any more [18:01:01] <superdump> because they don't conform, we can not give a crap about the channel order of the output [18:01:19] <superdump> but we can at least allow them to decode, as it seems to be a common issue [18:02:01] <peloverde> What worries me about that is channel counts changing on the fly [18:02:13] <superdump> hmm [18:04:04] <peloverde> I guess the trick is to save a locked configuration, and if the new configuration has the same count and locks then replace the old one and treat it naively, otherwise assume it's corruption and revert to the locked configuration [18:07:56] <peloverde> I guess we are going to have to deal with on the fly channel count changes for backwards compatible PS [18:08:20] <superdump> hrm [18:09:55] <peloverde> because backwards compatible PS is signaled inside the SBR data payload [18:10:25] <peloverde> So if there is no SBR Data yet, there is no PS [18:13:19] <superdump> they really did this with tape and glue didn't they? [18:13:59] <peloverde> There was no field for backwards compatible extensions inside SBR but outside of the data payload [18:14:23] <peloverde> So I guess the choices were to put it straight in AAC or put it in the payload [18:14:54] <peloverde> Really makes me wish i had access to USAC, I feel like I could find some spec defects before it's frozen [18:15:05] <peloverde> but sadly they insist on developing it in secret [18:15:10] <superdump> most probably [18:16:04] <peloverde> Another bad article on <video> codecs: http://www.zdnet.co.uk/news/cloud/2010/03/19/sting-in-the-tail-for-webs-vid… [18:16:24] <kshishkov> peloverde: probably people like you is the reason they develop it in secret [18:17:18] <kshishkov> peloverde: looks like they don't want spec to be usable for developing independent implementation [18:17:58] <peloverde> I guess so [18:18:31] <peloverde> I miss independent coding technologies, they needed independent implementations, it was part of their buisness model [18:18:59] <kshishkov> but they made SBR! [18:19:05] <peloverde> and they were actually helpful re: specification defects [18:19:08] <peloverde> SBR is great [18:20:41] <peloverde> implicit SBR is awkward, signaled SBR is fine [18:21:23] <peloverde> They should have never allowed implicit signaling, hierarchical backwards compatible is good enough, it just doesn't support ADTS [18:22:01] <peloverde> Also if anyone else wants to learn about SBR the mp3pro xmms plugin seems very RE friendly [18:22:32] <ramiro> kierank: what's wrong with it (version.sh)? [18:22:59] <_av500_> peloverde: just that nobody uses mp3pro... [18:23:17] <peloverde> I always see people complaining on the ubuntu forums about lack of mp3pro [18:23:24] <peloverde> so it appears a few suckers fell for it [18:23:26] <kshishkov> good, MP3 is crap [18:23:30] <kierank> ramiro: for whatever reason it doesn't work in mingw for me, not a big deal though. probably mingws fault [18:23:54] <_av500_> peloverde: our users never asked for it [18:24:03] <ramiro> kierank: could you be more specific as in what doesn't work? even if it's mingws fault I'm interested [18:24:06] <mru> one of the coding technologies guys taught my signals&systems class [18:25:02] <siretart`> is vrml really part of mpeg4? [18:25:04] <_av500_> peloverde: when do you do the 960 sbr? [18:25:10] <_av500_> for DRM [18:25:12] <mru> siretart`: _everything_ is part of mpeg4 [18:25:33] <peloverde> When someone adds a non-power-of-2 fft to ffmpeg [18:25:35] <kierank> ramiro: it doesn't output a version.h file at all but i haven't investigated why [18:25:49] <peloverde> we don't even support 960 LC [18:26:05] <peloverde> The reference software didn't support 960 until last year! [18:26:20] <kshishkov> so who cares? [18:26:52] <superdump> no one [18:27:23] <_av500_> so i have to use faad for it, shame :) [18:27:44] <superdump> you mean you actually have some 960 aac? [18:27:59] <_av500_> you can receive it easily [18:28:26] <_av500_> my coworker did the dream dm project [18:29:50] <peloverde> Why did DRM standardize on 960? [18:30:06] <mru> because it's non-standard of course [18:30:08] <ramiro> kierank: worked fine here. [18:30:14] <mru> peloverde: it's french [18:30:18] <mru> do I need to say more? [18:30:22] <kshishkov> no [18:30:23] <mru> remember secam? [18:30:47] <kierank> so how does 960 relate to french protectionism? [18:31:14] <peloverde> I never really understood 960 AAC, your short window is 8 samples shorter, that doesn't get you anything useful [18:31:48] <_av500_> peloverde: no idea why... [18:32:33] <peloverde> somebody who has an expensive library for awkward sized FFTs must have been on the committee [18:33:46] <aaronl> i wonder if such a library exists when fftw works great for weird fft sizes, and a bunch of commercial software uses it [18:33:48] <kshishkov> FFT-15 FTW! [18:34:18] <peloverde> fftw is GPL/commercial [18:34:24] <peloverde> so maybe them [18:35:00] <aaronl> ah, i didn't realize that [18:35:20] <kshishkov> reminds me one company asked the company I worked at if they could cook up something faster than Intel IPP FFT and FFTW [18:37:07] <peloverde> Totally possible if you are running on interesting hardware and can exploit a feature they don't [18:37:54] <kshishkov> so no - they asked for x86 [18:38:20] <kshishkov> and I was the only one there who knew something about FFT anyway [19:08:51] <ramiro> hmm, why is gcc sub'ing and add'ing to rsp in this function (win64): http://ffmpeg.pastebin.com/9hGE8wkQ [19:11:11] <jai> ramiro: it shouldnt have done that at -O3 [19:11:36] <ramiro> it's gcc 4.4.2 [20:03:01] * KotH just found a funny quote [20:03:14] <mru> enlighten us [20:03:16] <KotH> "... nobody programs in machine language anymore..." [20:03:22] <mru> rotfl [20:03:26] <KotH> from a book from 1971 [20:03:39] * mru did just that less than a month ago [20:04:07] <mru> wrote instructions directly in hex, that is [20:04:40] <KotH> i suspect that he meant asm with that [20:04:52] <mru> oh, I did that yesterday [20:04:59] <KotH> the language in programming changed quite considerably in the last 40 years [20:05:26] <KotH> and he is still talking about punch cards ^^' [20:07:07] <mru> KotH: btw, http://newteevee.com/2010/03/20/happy-birthday-gnutella-pioneering-p2p-prot… [20:07:17] <mru> apropos our discussion in brussels [20:12:38] <KotH> it's already been 10y? [20:12:39] <KotH> wow [20:14:02] * _av500_ feels older now [20:15:02] <_av500_> uni sent me new student card, i am in 40th semester now... [20:15:14] <KotH> lol [20:15:55] * _av500_ should apply for gsoc [20:16:06] <mru> lol [20:16:10] <mru> where's your qual task? [20:16:26] <_av500_> damn [20:16:31] <Dark_Shikari> lol [20:16:56] <Dark_Shikari> reminds me, the other day facebook sent me a care package with a guide to getting accomodated to the area/etc [20:17:00] <Dark_Shikari> it was only what, 9 months late? [20:17:13] <KotH> rotfl [20:17:40] <mru> I didn't know fb was that big a company [20:18:10] <_av500_> or has a very overworked hr team [20:18:14] <Dark_Shikari> 1000 employees last I was there [20:18:25] <KotH> night boys [20:18:41] <_av500_> dltbbby [20:18:50] <KotH> gesundheit [20:18:54] <mru> ah, that's the size when they start acting like they're 5x bigger than they are [20:19:09] <mru> and failing even worse than if they really were that size [20:58:44] <DonDiego> ffserver.c:1376: warning: implicit declaration of function ‘av_match_ext’ [20:58:48] <DonDiego> haha [20:58:51] <DonDiego> internal API abuse.. [20:59:40] <mru> that one is currently the subject of bikeshedding [21:01:43] <mru> as soon as that and the other one like it in ffserver are fixed I'll make such abuse an error [21:15:59] <DonDiego> please do [21:27:56] <CIA-30> ffmpeg: mru * r22609 /trunk/libavcodec/ (fft.h rdft.c): [21:27:56] <CIA-30> ffmpeg: Call rdft by function pointer [21:27:56] <CIA-30> ffmpeg: Call the RDFT by a function pointer like other FFT related transforms. [21:27:56] <CIA-30> ffmpeg: This makes instruction set optimized versions possible. [21:27:56] <CIA-30> ffmpeg: Based on patch by Alex Converse. [21:27:57] <CIA-30> ffmpeg: mru * r22610 /trunk/libavcodec/rdft.c: rdft: reorder functions to avoid static prototype [21:40:40] <CIA-30> ffmpeg: diego * r22611 /trunk/ffplay.c: [21:40:40] <CIA-30> ffmpeg: Move variable declaration, fixes the warning: [21:40:40] <CIA-30> ffmpeg: ffplay.c:1703: warning: unused variable `pos' [23:08:14] <peloverde> Have any specifics released about the Aldi DVD lawsuit? [23:15:06] <Dark_Shikari> peloverde: what's that? [23:17:13] <peloverde> "(DENVER, CO, US – 16 March 2010) – MPEG LA, LLC, world leader in alternative one-stop patent licenses, today announced that several patent holders in MPEG LA’s MPEG-2 Patent Portfolio License have filed separate patent enforcement actions in Landgericht Düsseldorf, Germany against Aldi Nord GmbH & Co. oHG (“Aldi Nord”) and Aldi Süd GmbH & Co. oHG (“Aldi Süd”), as well as Lidl Stiftung & Co. KG and Lidl Dienstleist [23:17:13] <peloverde> ung GmbH & Co. KG (“Lidl”), for infringing patents essential to the MPEG-2 digital video compression standard used worldwide in digital television broadcasting and DVD." [23:18:59] <CIA-30> ffmpeg: aurel * r22612 /trunk/libavcodec/error_resilience.c: fix compilation with --disable-everything --enable-decoder=mpeg2video [23:21:10] <Dark_Shikari> peloverde: ooh. [23:23:51] <peloverde> Except all I can find (in english) is that dumb press release that doesn't say who the plaintiffs are and which patents were violated [23:25:58] <DonDiego> all of the mpeg-2 portfolio i guess [23:26:22] <DonDiego> if you ship hardware you better watch out for the mpeg la [23:27:32] <peloverde> DonDiego, certainly not all of the portfolio [23:29:14] <peloverde> Despite claims of essentiality not everything there is truly essential [23:29:29] <peloverde> and it says that only "several" of the licensors are suing [23:29:30] <DonDiego> yes of course [23:29:57] <Dark_Shikari> honestly though, if you are shipping hardware, you can afford to pay license fees [23:30:06] <peloverde> Much like the RIAA, the MPEG-LA doesn't sue anybody, the actual owners wind up suing [23:30:09] <Dark_Shikari> (and equally, hardware is much easier to sue over) [23:30:10] <kierank> aldi dvd players are dirt cheap [23:30:20] <Dark_Shikari> kierank: and now we know why... ;) ;) [23:30:26] <Dark_Shikari> then again, aren't mpeg-2 fees really cheap? [23:30:27] <DonDiego> hardware does not have much of a profit margin [23:30:29] <kierank> they presumably got advice that the patent licence was unnecessary [23:30:43] <ShadowJK> or just thought that the manufacturer paid it [23:30:50] <_av500_> or are presumably clueless [23:30:55] <DonDiego> it's like paying protection money to the mafia, nothine more nothing less [23:30:59] <DonDiego> you work, they profit [23:31:01] <_av500_> ShadowJK: the chinese, no [23:31:13] <kierank> i wonder if aldi's dirt cheap satellite systems will be affected too [23:31:17] <Dark_Shikari> ShadowJK: the rule btw is that the seller pays [23:31:25] <Dark_Shikari> i.e. if I license my product X to company Y [23:31:31] <ShadowJK> I wonder how much the patents cost, must be a significant chunk of 19.90E DVD players :) [23:31:32] <Dark_Shikari> and company Y sells product X in box Z to users [23:31:37] <Dark_Shikari> company Y must pay the fees, not me. [23:32:03] <Dark_Shikari> ShadowJK: licensing fees are like $20-40 in a top-end fancy blu-ray player [23:32:03] <_av500_> he who imports to e.g. eu pays [23:32:06] <Dark_Shikari> with support for the kitchen sink [23:32:13] <Dark_Shikari> per unit [23:32:25] <_av500_> per snk [23:32:45] <kierank> Dolby E is $2-3k per device... [23:33:30] <kierank> aka daylight robbert [23:33:32] <kierank> robbery* [23:33:39] <_av500_> now that mpegla has extended h264 grace to 2016, they need money from elsewhere :) [23:33:51] <_av500_> so, aldi, blame theora! [23:34:05] <peloverde> the mpeg la isn't suing anyone [23:34:14] <_av500_> i know [23:34:25] <Dark_Shikari> _av500_: it's mostly a matter of setting an example [23:34:37] <Dark_Shikari> if you want everyone making DVD players to pay you 10 cents per unit [23:34:41] <Dark_Shikari> you have to go after the people who don't [23:34:47] <Dark_Shikari> even if it's not profitable to do so [23:34:52] <Dark_Shikari> because if you didn't, nobody would pay [23:35:04] <peloverde> agreed [23:35:11] <_av500_> yes [23:35:27] <Dark_Shikari> thus a lawsuit is effectively a signal of "we care about this particular market" [23:36:16] <_av500_> i guess most stuff here is licensed, aldi being a discounter maybe thought they get a discount :) [23:36:36] <peloverde> Still in theory you could draw up a list of actually essential patents and secure licenses independently of the MPEG-LA [23:36:56] <_av500_> if licensor would talk to you [23:37:06] <_av500_> and not send u to mpegla [23:37:14] <peloverde> Sometimes I wonder if the patent cross licensing agreements that microsoft strong arms people into include their media patents [23:37:23] <kierank> aldi are massive anyway so this will be interesting to watch [23:37:57] <peloverde> And some would argue that Samsung can't enforce thier patents against LGPL implementations [23:38:07] <_av500_> maybe they will switvh to ogg players... [23:38:43] <peloverde> I can't wait to go to Aldi and pick up some blurry Ogg-Ray discs [23:38:49] <ohsix> then what about the content people actually want to play [23:38:58] <kierank> peloverde, or AVS-Ray [23:39:02] <twnqx> janneg: 05 02 just hit 8.9G [23:39:08] <_av500_> it is aldi, they buy coz it is cheap [23:39:10] <twnqx> oh, 9.3 now [23:39:19] <ohsix> snownutray [23:39:34] <kierank> is aldi a reputable store in germany? because it isn't over here [23:39:40] <twnqx> no [23:39:46] <twnqx> it's a cheap store [23:40:01] * _av500_ sopsthere [23:40:09] * _av500_ shops there [23:40:21] <twnqx> me too, just... rarely, and specific [23:40:28] * _av500_ larts cheap aldi keyboard [23:40:44] <twnqx> i wouldn't buy computers there :P [23:40:51] <_av500_> nope [23:41:00] <microchip_> they come from Medion mostly [23:41:12] <twnqx> of course [23:41:13] <microchip_> and Medion is sh*t [23:41:13] <_av500_> their computers are expensive actualy [23:41:27] <twnqx> they are cheaper than mine [23:41:27] <_av500_> coz they come with kitchen sink that u dont need [23:41:30] <twnqx> (in every regard) [23:42:02] <twnqx> hm these scenes could be rendered if i upgraded my i7 to 12G... [23:42:13] <twnqx> 6G won't do... [23:42:20] <_av500_> twnqx: the last aldi 16core was not too ad, no? [23:42:22] <janneg> twnqx: that explains why it oom-ed on the 8G machine. the first take though which needs more than 8G [23:43:00] <twnqx> well, i'll shut the box for the night [23:43:04] * janneg must have missed the aldi 16core with 48G Ram [23:43:16] <twnqx> when the raid finished rebuilding... wonder why the one drive was kicked from both raids :X [23:43:18] <_av500_> aldi sued ftw :) [23:43:31] <twnqx> _av500_: i shop at aldi süd during the week [23:43:36] <twnqx> and north during the weekend :P [23:44:00] <microchip_> Lidl > Aldi :p [23:44:07] <kierank> lol [23:44:12] <_av500_> so u have the 16core and the track suit [23:44:29] <kierank> microchip_, theres about 100 levels of crap stores over here [23:44:29] <twnqx> :] [23:44:35] * janneg has to pass two bundesländer to get to aldi süd [23:44:41] <twnqx> heh [23:44:56] <twnqx> i'm passing between hessen (for work) and niedersachsen (for the weekend) [23:45:01] <twnqx> commuting* [23:45:08] <microchip_> kierank: not too many here :) [23:45:23] <kierank> there's netto and makro all sort of others [23:45:27] <_av500_> gee, nordhessen [23:45:52] <twnqx> actually [23:46:00] <twnqx> bonn is in NRW, not hessen, right? [23:46:20] <_av500_> last time i checked yes [23:46:23] <twnqx> so yeah [23:46:31] <twnqx> i'm in hessen only when i have to fix my servers >_> [23:47:23] <DonDiego> gnite [23:49:10] <twnqx> ok, blender doesn't die to ctrl-c [23:49:11] <twnqx> Oo [23:49:20] <Dark_Shikari> kill -9 [23:51:15] <janneg> twnqx: double ctrl-c [23:51:40] <twnqx> i sent like 100 :P [23:51:45] <twnqx> anyway, dead now [23:52:15] <twnqx> jobs 10 and 11 are completed, i hope to put them online tomorrow

1 0

IRC log for 2010-03-19
by irc＠mansr.com 20 Mar '10

20 Mar '10

[00:00:36] <ohsix> maybe you should post a bug for it :> [00:01:21] * Kovensky usually runs autogen with --help [00:02:29] <ohsix> thats a good idea, but the people normally running it are rolling tarballs, or developing from source control [00:06:48] * Kovensky still wonders if it was a good idea to commit configure and assorted files to version control [00:07:29] <mru> never was [00:07:37] <ohsix> its not, but circumstances vary, much like you wouldn't commit other generated files [00:07:38] <mru> but with autohell it's the only viable option [00:08:29] <Kovensky> lulz [00:08:40] <Kovensky> I think I did it accidentally, but decided to keep it so I wouldn't hear from MSYS users [00:12:28] <ohsix> sometimes you can get away with just generating some of the generated files for certain programs to a static copy or something; like a config.h thats presetup for stuff thats only available on windows [00:12:46] <ohsix> autotools can do some nutty stuff though, like generate compatibility wrappers [02:29:48] <MrNaz_yma> now that ffmpeg has lavf, how feasible is it getting yadif implemented within ffmpeg? decent interlacing would be a pretty big thiong [02:30:04] <mru> you mean lavfi [02:30:10] <mru> lavf is libavformat [02:30:14] <MrNaz_yma> oh [02:30:17] <MrNaz_yma> well them [02:30:19] <MrNaz_yma> then [02:30:26] <MrNaz_yma> please excuse me while i go back to my corner [02:30:29] <mru> patches welcome I guess [02:30:43] <MrNaz_yma> me? submit a patch? why do you hate ffmpeg so? [02:30:59] <mru> $$$ welcome [02:38:51] * kierank gives mru some zimbabwe $$$ [02:39:31] <mru> £££ welcome [02:40:28] <bcoudurier> humm where is my euro symbol :( [02:41:28] <astrange> option-3 on mac keyboards (us anyway) [02:50:35] <kierank> alt-gr + 4 on uk keyboards [03:00:28] <mru> http://daringfireball.net/linked/2010/03/18/wikipedia-ogg [03:00:33] <mru> well said [03:08:23] <ohsix> abscence of evidence isn't evidence of absence, you can look on commons and see all the junk on there [03:08:47] <mru> that's not what he said [03:09:21] <mru> he said that although wikipedia does host videos, they are not something you typically use wikipedia for [03:09:39] <mru> I've never watched a video on wikipedia [03:09:42] <mru> have you? [03:09:42] <ohsix> i know what he said, he elided how much time he spends looking for theora files on wikipedia [03:09:48] <ohsix> yes [03:10:04] <ohsix> back when it was just the java player even :P [03:10:10] <mru> when I use wikipedia, I'm looking for text 90% of the time [03:10:20] <mru> pictures for the rest [03:10:44] <mru> I can't recally _ever_ reading an article that had a video [03:10:47] <ohsix> not like you can actually look for video or audio on wikipedia; they accompany the article they're relevant to [03:11:31] <mru> so? [03:11:57] <mru> I read something on wikipedia more or less every day [03:12:07] <mru> and I've still not seen a single video [03:12:42] <mru> it is thus utterly irrelevant to me what format they're in [03:12:54] <mru> might as well be realvideo for all I care [04:27:45] <MrNaz_yma> [mpeg2video @ 0x1c4dd70]warning: first frame is no keyframe [04:27:51] <MrNaz_yma> "That's no keyframe!" [04:46:37] <peloverde> It's a battle station? [04:56:34] <Dark_Shikari> a fully operational battlestation? [04:57:03] <relaxed> It's too big to be a space station! [04:57:18] <Dark_Shikari> ohsix: the java player is great [04:57:22] <Dark_Shikari> it crashes firefox 100% of the time [04:58:21] <ohsix> never did here [04:58:45] <Dark_Shikari> I finally ended up upgrading to 3.5 even though it sucks so much just because of javascript performance [04:58:49] <Dark_Shikari> I mean, BALLS, 3.0 was slow [04:58:55] <Dark_Shikari> gmail was getting to take 30 seconds to load emails [04:59:10] <ohsix> i remember during an api interface change thing & the limbo plugin would crash all the time, but that was just running [04:59:17] <votz> Dark_Shikari: my favorite is when the prompt window just asking you if its ok to run a java applet crashes firefox [04:59:32] <ohsix> on x86_64 theres still no jit [04:59:51] <Dark_Shikari> ohsix: oh wow [05:00:02] <votz> ohsix: have they said why? [05:00:21] <votz> 64 bits is just TOO much [05:00:23] <ohsix> what extensions? 30sec is bizarre & the "js going slow, stop?" would have appeared even for the chrome if it was js [05:01:13] <Dark_Shikari> ohsix: chrome ran it faster though [05:01:17] <ohsix> theres no "why", nanojit didn't have an x86_64 backend when they switched, it does now; but with their release stuff it wont be until 3.7 (though you can run it now, if you want) [05:01:19] <Dark_Shikari> extensions? a bunch but mostly trivial ones [05:01:22] <Dark_Shikari> adblock is probably the primarily slowdown [05:01:42] <ohsix> chrome is every part of the browser that isn't a webpage, not chrome the browser [05:02:20] <ohsix> i haven't seen anhything like that with adblock, but the tab thing for certain elements has a storied history [05:03:09] <Dark_Shikari> oh, I thought you meant google chrome [05:03:39] <ohsix> theres a cycle collector that will unfuck most, even bad extensions still in the wild; but bindings can still leak all over if they aren't properly written [05:04:07] <ohsix> nah, it was a general term for "the bits around the edges" before google chrome even existed :P [05:05:02] <ohsix> 30sec bespeaks an extension/nativre code plugin doing something awful, though [05:06:37] <ohsix> it does give you enough rope to hang yourself though, people tend to be fascinated with extensions when they first switch, too; and they generally leave em there even if they dont use them, so its a cruftbomb waiting to happen [05:07:53] <Dark_Shikari> well lets look at mine [05:07:58] <Dark_Shikari> adblock plus: critical [05:08:00] <ohsix> in my main session i run with all the native plugins disabled, so they don't lurk in some far off tab [05:08:02] <Dark_Shikari> chatzilla: don't use it anymore [05:08:09] <Dark_Shikari> cutemenus: well, it makes the menus nicer. [05:08:17] <Dark_Shikari> download statusbar: awesome, the built-in download manager is utter garbage [05:08:21] <Dark_Shikari> downthemall: amazing [05:08:30] <Dark_Shikari> fireftp: awesome, the builtin ftp client is garbage [05:08:33] <Dark_Shikari> flashblock: critical obviously [05:08:36] <Dark_Shikari> greasemonkey: sorta cool [05:08:40] <Dark_Shikari> rikaichan: awesome [05:08:44] <ohsix> ahhh download statusbar, thats not broken itself but can lead to huge delays [05:08:50] <Dark_Shikari> menu editor: critical for removing all that junk the extensions add [05:08:54] <Dark_Shikari> organize status bar: same [05:09:00] <Dark_Shikari> resizable text area: OMG WHY IS THIS NOT IN TRUNK [05:09:05] <Dark_Shikari> screengrab: cool [05:09:21] <ohsix> the download history can get years long with it; and that eventually slows stuff up tons [05:09:43] <Dark_Shikari> searchbar autosizer: same as resizable text area [05:09:44] <Dark_Shikari> stylish: meh [05:09:46] <ohsix> i dunno if the moved downloads from rdf to sqlite/places at all; they might have [05:09:48] <Dark_Shikari> tab mix plus: critical [05:09:52] <Dark_Shikari> tree style tabs: the single best extension in firefox history [05:09:58] <Dark_Shikari> url fixer: cool beans [05:10:01] <peloverde> because the mozilla devs are complacent jerks? [05:10:03] <Dark_Shikari> so yeah, basically all of my extensions are sorta important. [05:10:10] <elenril> you dont' use noscript? [05:10:15] <Dark_Shikari> no, noscript is useless [05:10:17] <Dark_Shikari> it breaks the entire internet [05:10:24] <ohsix> tabmixplus is another one that likes to break often, and taking ff with it too [05:10:28] * elenril wonders how he didn't notice [05:10:35] <peloverde> There is a ton of stuff where they basically said this is too much work/no one will ever want this until chrome did it and they back peddled [05:10:43] <astrange> i use wp-hashcash and people with noscript always end up in the spam queue [05:11:06] <astrange> but people with noscript are always really angry so i don't bother approving the comments sometimes [05:11:15] <ohsix> tabkit covers a lot of those too, and its less omgexplode-y [05:12:19] <ohsix> other than that i dont see any problematic ones [05:13:37] <ohsix> mines adblock, flashblock, greasemonkey (in a pinch can bodge anything, even stuff you'd want an extension for), tab counter (for no real reason, 361 tabs open now :), tab history & tab kit [05:13:38] <Dark_Shikari> I recall adblock creates lots of lag [05:13:40] <Dark_Shikari> due to its regexes [05:13:51] <Dark_Shikari> oh yeah, and my firefox crashes every 3 days [05:13:54] <Dark_Shikari> clockwork [05:13:59] <Dark_Shikari> I think it's because it's running out of address space [05:14:11] <Dark_Shikari> and firefox, being crap, doesn't have graceful handling of malloc failures. [05:14:29] <ohsix> adblock wasn't that bad even when i was doing my own bad lists, they have subscriptions now & vet for expensive patterns before they get in [05:14:30] <Dark_Shikari> then again, it doesn't seem to know how to free memory anyways [05:14:55] <ohsix> you cant be graceful about malloc failing [05:15:03] <Dark_Shikari> sure you can. you can at least tell the user what happened [05:15:19] <Dark_Shikari> x264 tells you what failed, where it failed, and closes without a segfault [05:15:20] <ohsix> why, when they can just suspect? :P [05:15:47] <ohsix> are you running without a swap file? [05:16:03] <ohsix> /partition [05:16:03] <Dark_Shikari> no [05:16:09] <Dark_Shikari> default windows 7 settings [05:16:15] <Dark_Shikari> _address space_. it caps at 2 gigabytes [05:17:05] <peloverde> Really? I don't seem to run into that? [05:17:21] <ohsix> heh its not as cut & dry as that [05:17:58] <peloverde> I thought it was 16 GB for home premium? [05:18:16] <Dark_Shikari> 32-bit processes [05:18:19] <Dark_Shikari> have a 2gb address space limit. [05:18:20] <Dark_Shikari> period. [05:18:21] <Dark_Shikari> full stop. [05:18:30] <peloverde> Dark_Shikari: 32-bit is obsolete [05:18:32] <Dark_Shikari> (unless you compile with and run with /LARGEADDRESSAWARE, in which case they have 3.) [05:18:37] <ohsix> address space availalable to an app is different than page table chicanery [05:18:38] <Dark_Shikari> peloverde: And yet firefox still has no JIT for 64-bit ;) [05:18:56] <peloverde> Yet another reason I don't use firefox [05:19:18] <ohsix> its not as big a difference as you'd suspect [05:19:45] <ohsix> the chrome tends to get pulled into webpages that are slow though, which is a drag [05:19:55] <peloverde> I think Mozilla has creeped up to the top of my organizations-I-want-to-see-fail list [05:20:24] <Dark_Shikari> peloverde: The really funny thing will be when IE9 comes out [05:20:42] <Dark_Shikari> remember when Mozilla touted them as supporting all the web standards and IE not [05:20:43] <ohsix> heh, then the magic vacuum left in its wake can generate The Singularity(tm) [05:20:56] <Dark_Shikari> and now we're going to have everyone supporting stuff except firefox [05:21:20] <Dark_Shikari> Then again, firefox should have died in a fire around the time it started using 1.5 gigs of memory [05:21:40] <ohsix> vma size (brk size) != rss [05:21:49] <peloverde> And Opera, who are their own special brand of crazy [05:22:09] <Dark_Shikari> ohsix: I'm talking about actual used memory, not commit size [05:22:19] <Dark_Shikari> opera are funny [05:22:24] <Dark_Shikari> opera is like the plan 9 of browsers [05:22:28] <Dark_Shikari> or the BeOS [05:23:17] <ohsix> 32303 ohsix 21 1 2250M 921M 21580 S 20.0 32.6 8h31:26 0 0 `- /usr/lib/firefox-3.5.8/firefox [05:24:23] <ohsix> oh, wait there is the one thing without jit; it tends to use 5% cpu servicing timers and dom junk even when otherwise "idle", with jit it barely breaks 1% for the hugest sessions [05:27:31] <ohsix> computers i've tried to restore my ff session on in other browsers (open all bookmarks, wait an hour) have failed it hard, ie still uses heavyweight processes too; so opening a new "tab" makes the chrome go through the motions while you wait for an shdocvw instance to appear [05:28:38] <ohsix> someone else can make the argument for or against having 3-500 tabs open in the first place; but at least it works still :P [05:29:03] <Dark_Shikari> it's the only way to browse tvtropes [05:29:12] <Dark_Shikari> I use a depth-first search [05:29:20] <Dark_Shikari> and even that spawns a huge ton of pages [05:29:23] <Dark_Shikari> breadth-first must be even worse [05:29:27] <ohsix> it does have one "heap" problem thats still present on windows though, it indiscriminately uses gdi objects without regard to the limits [05:30:27] <ohsix> plus it creates a brush per object & never releases them, lik CreateBrush to create a white one _every time_, wheb theres getstockobject & a fixed table of free ones that include black [05:31:03] <ohsix> once it hits 10000 its quite a show, windows actually starts to fail :P [05:31:33] <Dark_Shikari> lol [05:32:36] <Dark_Shikari> http://en.wikipedia.org/wiki/File:IE7_Errors_caused_by_10000_GDI_Objects_2.… [05:32:41] <ohsix> re" tvtropes, for real; any wiki worth a shit is usually a tabgasm waiting to happen, one reason idon't really like wiki's is i cant control myself & end up with a month long reading task [05:33:30] <ohsix> notice he took that with a camera [05:33:54] <ohsix> cuz windows is broke, it cant even create a compat dc for a clipboard object [05:34:01] <Dark_Shikari> yup [05:34:01] <Dark_Shikari> lol [05:35:09] <ohsix> that gdi out of resources thing is a good example of why you cant really "handle" those situations, windows certainly cant provide ui to inform you of the problem [05:35:41] <Dark_Shikari> of course you can handle it [05:35:43] <Dark_Shikari> oomkiller-style [05:35:59] <ohsix> for OOM/malloc = null, you need some stack or otherwise to dig you out of an unknown program state, or you wrap allocations & fail insitu [05:36:19] <Dark_Shikari> the latter is fine [05:37:51] <ohsix> depends on the type of software, if its at all sensitive to memory consumption it should probably just be run when the environment is suitable; people try and check every allocation & stuff though, and not with a wrapper; that is fail [05:38:33] <ohsix> insitu warnings don't really inform anyone of the whys [05:41:26] <ohsix> and unwinding, or hacks to get around it for proper diagnosis just litter the place up, its best to just crash, then someone who cares can dig through the core file; it a really rare circumstance to such mindfully handle [05:42:11] <Dark_Shikari> it's nice to tell the user what went wrong though [05:42:14] <Dark_Shikari> particularly with x264 at least [05:42:18] <Dark_Shikari> a ton of people were reporting "crashes" [05:42:22] <Dark_Shikari> when it was really avisynth eating up all the ram [05:42:43] <ohsix> def, but it depends on the software [05:43:40] <ohsix> if its something like that with interactions then the people reporting the bug or doing triage probabbly didn't do due diligence with reproducing the circumstance [05:43:44] <Dark_Shikari> of course [05:44:42] <ohsix> if its ff theres really nothing to do but to report a crash to upstream via apport or the google reporting thing, or that other thing moz used to use, even for OOM [05:45:23] <ohsix> though they might not get a chance at it if some other software kills it first [05:46:48] <ohsix> fwiw windows still reports to a window station when its "resources" are low, it doesn't say what, and it just suggests closing things, if you miss the app thats got all the stuff, the notice comes up a bit later; repeat until system is nonresponsive [05:47:37] <ohsix> thats mostly per window station type resources though, or when a service starts failing acquiring handles [05:49:13] <ohsix> firefix has a pretty big resource punchdown in the event it starts getting anywhere near system capacity, it cant do shit about what some ad-hoc extension does though [05:50:07] <ohsix> http://msdn.microsoft.com/en-us/library/aa366586%28VS.85%29.aspx [05:50:47] <ohsix> ff is kind of like its own os or bigtime db when it comes to memory use, its really amazing that it even scales as far as it does on windows [05:51:27] <ohsix> if you have 2 self tuning memory hogs, stuff tendsw to get broke real fast as their usage policies battle it out for swap bandwidth [05:56:19] <ohsix> windows is in rare form when theres no swap; and globalmemorystatus gets very noisy to boot [06:21:38] <jai> hmm, videolan wants to rewrite their mkv demuxer [06:21:52] <jai> can't they just use lavf [06:22:02] <Dark_Shikari> NIH [06:22:16] <jai> :( [06:22:20] <kshishkov> it's funny when applied not to FFmpeg [06:22:29] <elenril> lavf mkv demuxer f4ilz0rz [06:22:36] <jai> elenril: elaborate [06:22:48] * kshishkov thinks about having RTMP as an external protocol handler [06:23:05] <kshishkov> jai: not enought metadata for him obviously [06:23:12] <kshishkov> *enough [06:23:44] <jai> lol [06:24:15] <jai> also, they are running a task for dvda support [06:24:23] * elenril shoots kshishkov [06:24:26] <jai> maybe that can be done in ffmpeg instead [06:24:34] <elenril> it butchers ass subs [06:24:40] <av500> how? [06:24:44] <ohsix> ass :D [06:25:05] <elenril> av500: just try mplayer -demuxer lavf <some random anime> [06:25:08] <ohsix> libass is busted to a degree everywhere else too [06:25:36] <ohsix> of the last few bugs i've reported to some media junk, 2 ended up being ASS related [06:26:13] <kshishkov> elenril: seems fine [06:26:25] <jai> elenril: worked for me last i tried [06:26:29] <ohsix> with the embedded fonts? [06:26:37] <av500> elenril: besides rewrtiting the timestamp, what else is there except to output the sub as stored? [06:26:41] <ohsix> there can be several, its quite lame [06:26:45] <jai> though i dont have a lot of ass [06:26:55] <av500> jai: :) [06:26:56] <jai> err, *media with ass streams [06:27:17] <ohsix> do you want some? there are some xdcc bots with the "samples" wink wink, that i have [06:27:33] <kshishkov> since MPlayer renders them as any other non-fancy text subtitles, what's the difference? [06:27:57] <elenril> Warning: no style named '0:00:06.77' found [06:28:06] <jai> Dark_Shikari: ah, I see audio input support for x264 [06:28:47] <jai> that would pose some competition for ffmpeg :) [06:28:48] <kshishkov> jai: why, you don't like your audio encoded as H.264? [06:28:55] <jai> kshishkov: lolwut [06:29:08] <jai> they want vorbis and aac output support [06:29:21] <kshishkov> and h.264 in ogg [06:29:25] * drv encodes all his important documents with Theora, works better than a shredder [06:29:33] * av500 wonders if x264 needs a dll codec wrapper too.... [06:30:00] <ohsix> hah, wild; they are really broken, lemme post a screen [06:30:12] <kshishkov> av500: it will use once from lavc eventually ;) [06:31:40] <av500> so I can use binary codecs in lavc by using x264 with a special flag :) [06:32:40] <drv> x264 --install-windows [06:33:20] <av500> x264 -i random.vid -o made_for_mozilla.ogg [06:33:46] <drv> i doubt they'd like h.264 any better even if it were in ogg [06:33:49] <ohsix> http://img715.imageshack.us/img715/913/bustedass.png [06:33:54] <jai> x264 --subvert-ffmpeg [06:34:10] <kshishkov> drv: tHeora.264 in Ogg then [06:34:27] <elenril> ohsix: fail [06:34:36] <ohsix> ya [06:34:39] <av500> ohsix: and there is tearing too! [06:34:43] <elenril> you didn't -ass [06:34:45] <ohsix> dunno what that tear is [06:34:54] <kshishkov> ohsix: looks like you also need to rename directory with those files [06:35:23] <ohsix> hur [ass] [0x2517270] Warning: no style named '0:00:17.12' found, using 'Default' [06:35:40] <ohsix> meh, its /media/9<tab> [06:35:50] <ohsix> its one of the internal volumes without a label [06:41:38] <thresh> morning [06:42:48] <jai> moro [06:43:22] <thresh> yes, sorry :( [06:43:36] <jai> wat [06:43:59] <kshishkov> something went wrong so it appears to be not so bad morning for thresh [06:45:35] <av500> his kbd swallowed an "o" [06:48:21] <kshishkov> taken by FSB to interrogation maybe [06:53:42] <thresh> tsss. [06:55:35] <av500> keylogger acting up [06:56:08] <kshishkov> keystealer [06:56:10] <thresh> every ISP in .ru has hw to monitor traffic for FSB [06:56:20] <av500> and it works? [06:56:30] <av500> it does not replay last month traffic like the cameras? [06:56:32] <thresh> so that effectively makes you watched by FSB as well :) [06:56:34] <kshishkov> in traditional Russian way [06:56:38] <thresh> well, not quite sure [06:56:44] * av500 waves at FSB [07:02:54] <kshishkov> av500: just hope they don't have peering agreement with Stasi [07:03:56] <votz> jai: ping [07:04:11] <av500> kshishkov: I will ask my commanding officer :) [08:13:56] <twnqx> 20603 charlie 20 0 6515M 5813M 1690M S 796. 36.1 16:40.86 blender -b ./production/scenes/0 [08:13:56] <twnqx> 20382 charlie 20 0 6543M 5919M 1755M S 785. 36.8 34:38.74 blender -b ./production/scenes/0 [08:14:03] <twnqx> so it is possible to run two blenders :P [08:15:19] * twnqx needs to figure out tasksets to stop the threads from migrating to cpus further away from the memory [08:17:08] <twnqx> meh, taskset can be used retroactively, but numactl can't... [08:18:57] <jai> votz: pong [08:29:19] * av500 reads Kalman, Hilbert and Wiener in the same patch.... [08:30:34] <twnqx> Wiener Würstchen? [08:30:39] <kshishkov> av500: then it must to do something with matching filtration [08:30:44] <kshishkov> and denoising [09:27:54] <jai> btw, we should propose the halting problem for gsoc and see how many proposals we get :) [09:29:13] <kshishkov> it seems to have to relation to FFmpeg [09:30:06] <jai> i bet we'll still receive a huge bunch of proposals [09:30:17] <kshishkov> so? [09:30:37] <kshishkov> how it will benefit FFmpeg or can benefit at least? [09:30:48] <jai> no way at all, its just funny [09:31:54] <kshishkov> funny thing is ralf encoder [09:32:15] <jai> O_O [09:34:24] <kshishkov> or at least commit Flash Screen Video 2 encoder [09:39:01] <pJok> goda morgonor, kshishkov :) [09:39:50] <kshishkov> hej-hej [09:42:46] <janneg> jai: as long as the qualification task for the halting problem is solving traveling salesperson problem in exponetial time it would be fine [09:43:05] <jai> janneg: lol [09:43:13] <kshishkov> janneg: even proving it can be done is enough ;) [09:43:44] <av500> janneg: I guess it will not work on a 4GB machine though... [09:44:01] <kshishkov> "FFmpeg 0.7 - powered by Improbability Drive" [09:44:15] <pJok> infinite improbability drive [09:44:17] <jai> > "I can't prove that an algorithm, but neither can michael" > Patch looks ok [09:44:26] <jai> +exists [09:44:40] <av500> kshishkov: with x264 gettings all the lavc/lavf features, I think we can reduce 0.8 to ffplay.c [09:45:27] <janneg> jai: "neither micheal can disprove that an algorithm doesn't exists" patch ok [09:45:40] <jai> :) [09:46:54] <kshishkov> do something easier - like bugfree GCC for embedded platforms [09:47:43] <pJok> why not just a bugfree gcc overall? [09:47:47] <av500> and it is bugfree for non embedded? [09:48:02] <twnqx> pJok: you'd need to make that a gsoc project first [09:48:05] <kshishkov> it's less noticeable there [09:48:26] <pJok> twnqx, i don't think $5k pay would be enough for that task ;) [09:48:29] <av500> then better improve qemu to run x86 binaries on embedded :) [09:48:30] <merbzt> we need more reasonable projects that people can do [09:48:45] <kshishkov> ATRAC3+ [09:49:08] <merbzt> yeah, that can be added [09:49:16] * av500 saw a minidisk player for sale in berlin 2mo ago... [09:49:33] <kshishkov> av500: you can still buy record players here I think [09:49:54] <twnqx> i wonder if i should get one or two of the last technics DJ players [09:49:56] <kshishkov> merbzt: have they finished REing bitstream format? [09:50:06] <av500> kshishkov: that I can understand more acually :) [09:50:06] <merbzt> don't think so [09:55:06] <kshishkov> av500: BTW, soon it will be 325th anniversary of The Composer's birthday. Any preparations in Germany? [09:56:53] <av500> 2 of them actually [09:57:32] <kshishkov> 2 of what? [09:57:49] <janneg> birthdays? [09:58:01] <kshishkov> could be [09:58:09] <av500> händel too [09:58:09] <kshishkov> 21th/31th old/new style [09:59:01] <kshishkov> it should have been celebrated by now [09:59:57] <av500> they did not invite me [10:00:07] <av500> but there is/was stuff: http://www.google.com/search?as_q=bach+325&lr=lang_de [10:01:10] * kshishkov remembers hearing nothing about celebrating 200th birthday of Gogol at Ukraine last year. [10:01:46] <superdump> kshishkov: <anything>-first is abbreviated <anything>1st [10:02:16] <superdump> and 2nd, 3rd [10:02:26] <superdump> but the rest are th, i think [10:02:39] <twnqx> yes indeed [10:02:58] <thresh> 11st [10:03:00] <thresh> ;P [10:03:16] <twnqx> eleventh, it's not ten-first [10:04:36] * pJok hands Arthur_Dent a cup of tea [10:05:01] <jai> hello pJok :) [10:05:15] <pJok> afternoon jai :) [10:32:31] <tborg> Do we have a pendant to get_unary() somewhere in libavcodec? [10:39:38] <astrange> a which? [10:42:37] <tborg> me? in other words: a counterpart to get_unary() [10:43:04] <tborg> something better than put_sbits(.., n, ~0) (if that would work...) [10:46:10] <kshishkov> superdump: yes, that's what you got without thinking first. It's still better than "2rd floor" though [10:48:23] <kshishkov> s/got/get/ [10:48:24] <superdump> :) [10:48:51] <MrNaz_out> hey i work on the 2rd floor [10:48:54] <superdump> yeah, 11th, 12th, 13th are special [10:49:45] <kshishkov> unless it's tenty-first, tenty-second and tenty-third [10:50:08] <kshishkov> (could happen after language reform in USA I think) [10:50:17] <superdump> :) [10:50:33] <MrNaz_out> language reform in the USA? i think that'd involve just discarding half of the vocabulary [10:50:38] <MrNaz_out> "you're" would go first [10:50:45] <av500> ur [10:50:48] <MrNaz_out> followed by "they're" [10:50:51] <kshishkov> y'all [10:51:05] <MrNaz_out> and their [10:51:07] <selves> hello, I am new to ffmpeg, actually i need to use ffplay to play my media content.. I am getting the media content through streaming in bytes chunks.so either I can save the bytes to a file and then play the file through ffplay. but I need to input the bytes every time I receive it.. can any body tell me how I can implement this.or where to start from?? thanks [10:51:41] <av500> -> #ffmpeg [10:52:18] <kshishkov> MrNaz_out: Americans misspell worlds like "colour" and "centre" already [11:44:22] <KotH> --- [11:44:24] <KotH> Hi, [11:44:24] <KotH> This is a very nice collection of various media files. [11:44:24] <KotH> I think I'll need it all. [11:44:26] <KotH> --- [11:44:42] <twnqx> lol [11:44:44] <kshishkov> pokemons.mplayerhq.hu? [11:55:54] <astrange> who wants to write get_cabac() for arm? it might be useful [11:56:40] <kshishkov> look into mru direction [12:52:09] <twnqx> heh [12:52:16] <twnqx> nodelocking blender wasn't the best idea :P [12:52:52] <twnqx> poor thing was oom killed :( [12:54:14] <KotH> join the club [12:54:38] <mru> hey, you guys are lucky [12:54:46] <mru> it *killed* my quadcore [12:55:02] <twnqx> how's that even possible? [12:55:12] <av500> killed the I7? [12:55:35] <merbzt> so a 4gb machine wont do it ? [12:55:45] <twnqx> that node had 8G... [12:56:00] <twnqx> well. has. [12:56:09] <merbzt> omg :( [12:56:23] <merbzt> is it caused by the resolution ? [12:56:41] <twnqx> guess i'll put it on the list of rerenders without nodelocking [12:56:55] * janneg hasn't seen a single oom since the upgrade to 6G [12:57:01] <merbzt> ok [12:57:41] <janneg> merbzt: only partially, most of the memory seems to be used for scene data [12:58:33] <janneg> i.e. it doesn't use much less memory to render at cif [12:58:42] <mru> av500: no, not the i7 [12:58:42] <merbzt> is it only one segment that is buggy ? [12:58:50] <mru> it killed the old c2q [12:58:54] <av500> ah [12:58:57] <twnqx> physically? [12:58:58] <av500> mercy killing [12:59:00] <mru> just tried again, doesn't boot [12:59:03] <twnqx> wow [12:59:05] <twnqx> bad fan? [12:59:05] <mru> not even the bios screen [12:59:18] <merbzt> mru: blown caps ? [12:59:28] <mru> I'll have to open it and check [12:59:44] <merbzt> I revived 2 c2d at work with [12:59:47] <merbzt> blown caps [13:00:02] <twnqx> on the mobo? [13:00:13] <twnqx> or on the cpu? :> [13:00:19] <mru> the c2 has thermal protection, right? [13:00:28] <twnqx> afaik yes, though i never triggered it [13:00:30] <merbzt> yes [13:00:39] <twnqx> the c2d here in the laptop hits ~90°C [13:00:42] <merbzt> intel has since the p3 afaik [13:00:53] <mru> so even with bad cooling, it wouldn't toast the cpu permanently [13:00:59] <av500> should not [13:01:00] <merbzt> twnqx: on the mobo [13:01:15] <merbzt> mru: should just lockup [13:01:26] <mru> but not permanently... [13:01:34] <mru> as in after cooloff and reboot [13:01:37] <merbzt> yes [13:01:51] <twnqx> don't they just throttle? [13:01:57] <merbzt> does the box (fans, harddrive) start ? [13:02:18] <mru> fans start, and some LEDs light up [13:02:23] <mru> vga stays dead [13:02:28] <merbzt> ok, blown cap then [13:02:30] <mru> kbd too [13:02:33] <twnqx> no beeps from the speaker? [13:02:42] <mru> it never beeped [13:02:55] <merbzt> the 2 I fixed din't beep either [13:02:55] <av500> speaker coupling cap also dead :) [13:03:19] <merbzt> but started enough to light some leds and spin the fan [13:03:52] <mru> I'll open it and have a look later [13:04:25] <merbzt> the cap farads just need to be close enough [13:04:32] <twnqx> and low esr [13:04:33] <merbzt> voltage the same or higher [13:05:31] <mru> I know how filter capacitors work [13:05:45] <twnqx> those usually aren't really filters :P [13:05:56] <mru> not in the audio sense, no [13:06:09] <twnqx> also not in the voltage stabilization sense [13:06:20] <twnqx> more like parts of the charge pumps [13:06:39] <mru> I don't know yet what's dead [13:06:55] <twnqx> let's hope it's just some caps [13:08:04] <twnqx> hm [13:08:13] <twnqx> process stays below 6G [13:08:19] <twnqx> why was it OOMed :S [13:09:31] <ramiro> twnqx: maybe you should close firefox and google earth =) [13:09:47] <twnqx> that things doesn't even have X running [13:09:50] <twnqx> thing* [13:10:06] <ramiro> wow, google earth through libcaca? nice... [13:10:12] <twnqx> :P [13:10:21] <ramiro> that would be funny actually [13:10:27] <twnqx> that would be something to to actually [13:10:35] <twnqx> "Xcaca" [13:10:50] <twnqx> world's first textmode X server [13:12:12] <twnqx> hm, completed now without OOM [13:12:14] <twnqx> funny [13:14:07] <twnqx> rendering time is about 1:15h cpu time... fer frame [13:14:13] <twnqx> per* [13:14:27] <twnqx> we should get michael to optimize blender :P [13:18:52] <janneg> rendering time differs wildly, from 5 minutes to over 1 hour real time on a quadcore [13:19:35] <twnqx> so i got all the hard scenes? :P [13:21:28] <janneg> seems so [13:24:52] <merbzt> janneg: have you talked to the peach guys about the broken scenes ? [13:32:37] <janneg> no, it's imho too funny. but it would a nice thing to do [13:33:18] <av500> wasnt the plan to replace the eyes with zigzag logo? :) [13:36:05] <twnqx> wtf [13:36:20] <twnqx> i'm trying to redo an order at digikey it did half a year ago [13:36:28] <twnqx> NONE of the components are in stock :S [13:36:34] <av500> :) [13:36:56] <av500> companies dropped a lot of stock during the "recession"... [13:37:07] <av500> and manufs stopped a lot of production [13:37:30] <twnqx> estimated shipping date... 20.05.2010 [13:37:32] <twnqx> THANK YOU [13:38:19] <av500> YOURE WELCOME [13:39:21] <av500> twnqx: what parts are you after? [13:39:36] <KotH> twnqx: that's nomral [13:39:50] <twnqx> but i can't even place an order :X [13:39:55] <twnqx> like "ship when you got it" [13:40:21] <twnqx> av500: stepdown voltage regulators, bus tranceivers [13:40:49] <twnqx> hm, they have the 1.2V stepdown regulators [13:40:52] <av500> no alternatives? [13:40:53] <twnqx> 32 pieces left :S [13:41:01] <twnqx> well.. i have the PCBs.... [13:41:23] <twnqx> no fitting alternatives [13:43:22] <twnqx> hm avnet has stock... [13:43:29] <twnqx> do they even have an online shop for germany [13:43:53] <av500> maybe some downstream distri [13:43:55] <av500> of them [13:43:56] <KotH> twnqx: we've the same prob with nearly everythng that is not 100% 0815 [13:44:11] <twnqx> av500: do you know any? :X [13:44:17] <av500> EBV [13:44:18] <KotH> twnqx: all manufacturers closed fabs and now can't get up to speed with production [13:44:36] <twnqx> and keep in mind, i don't want to buy full reels :P [13:44:50] <av500> well, there arent any anyway :) [13:45:27] <twnqx> not in stock with digikey, no. [13:45:48] <av500> try speorle [13:45:52] <av500> err spoerle [13:46:09] <twnqx> hm [13:46:21] <twnqx> EBV has 0 stock as well [13:46:38] <KotH> findchips.com? [13:46:50] <av500> chinese spot market ftw! [13:47:04] <twnqx> spoerle has 0 stock as well :P [13:47:11] <av500> reichelt? [13:47:15] <twnqx> nah, the point is i don't care if delivery takes 2 months [13:47:18] <twnqx> lol reichelt [13:47:23] <av500> reichelt is not bad [13:47:34] <av500> they are not dk of course [13:47:36] <twnqx> for the parts i'm after they are :P [13:49:18] <twnqx> TPS62205DBVT, TPS62207DBVT, SN74CB3T16210DGVR [13:49:36] <twnqx> and those are the first three i tried :X [13:50:31] <av500> thats all TI stuff [13:50:36] <twnqx> yes. [13:50:39] <av500> TI shutdown a lot mid last year [13:50:51] <av500> that is the fallout [13:51:02] <twnqx> yeah, some are already late for delivery to digikey even [13:51:23] <av500> I guess you need to order a lot of free Maxim samples :) [13:51:57] <twnqx> well.. are they pin compatible? :X [13:52:31] <twnqx> XC3S250E-4VQG100C weee xilinx is available [13:53:23] <av500> \o/ [13:58:39] <twnqx> so it really is a TI problem... gah [13:58:53] <av500> not only [13:59:10] <av500> industry is full of it If I am to believe free trade magazines... [13:59:34] <nfl> jai: are u there? [13:59:44] <twnqx> CSX325FHC48.000M-UT <- also not available [14:00:04] <twnqx> but maybe, just maybe, there's a replacement part... [14:00:39] <jai> nfl: yeah [14:00:46] <nfl> jai: can i pm you? [14:01:08] <jai> nfl: k [14:46:24] <superdump> merbzt: do you know what the missing features in the qcelp decoder are? [14:46:35] <superdump> i've been marked as a mentor for it but i don't know what's missing [14:46:43] <superdump> i thought reynaldo had finished the postfilters [14:46:48] <superdump> so it's done afaik [14:47:16] <superdump> and why is there "Write or improve WB spec"? [14:48:02] <BBB> because the spec for NB sucked [14:48:08] <BBB> so they rewrote it [14:48:16] <BBB> I think the qcelp task can be removed [14:48:20] <BBB> I wasn't sure what it meant either [14:48:39] <merbzt> superdump: post filter afaik [14:48:53] <superdump> i thought that was done [14:49:00] <merbzt> might have been [14:49:01] <superdump> BBB: you mean i rewrote it ;) [14:49:05] <merbzt> I don't remember [14:49:12] <BBB> oh yes it was you [14:49:13] <superdump> we can check [14:49:15] <BBB> so WB same thing [14:49:17] <BBB> you should know :) [14:49:19] <superdump> it's the tilt/blah filter [14:49:31] <superdump> BBB: well, i don't think it will be so bad now i've done it once [14:49:35] <merbzt> superdump: no no, lets inestead argue on the internet [14:49:47] <superdump> lol [14:50:54] <merbzt> 2 crap keyboards or a broken usb hub... [14:52:44] <twnqx> mh? [14:55:31] <merbzt> I get misstrokes and key repeatings on 2 different keyboards connected to this computer [14:55:43] <av500> keylogger acting up? [14:55:51] <merbzt> must be [14:56:09] <merbzt> it's all connected to a crap monitor hub [14:56:22] <merbzt> guess it is the weak link [14:57:28] <KotH> the bus is only as strong as its weakest hub! [14:57:54] <av500> I once had a monitor with a hub, 2port, usb1 [14:58:02] <av500> it was obsolete before it was designed... [14:59:04] <merbzt> would work for a keyboard and a mice [14:59:26] <av500> youcan see how well it works for you :) [15:03:24] <pJok> a shame ffmpeg doesn't support -r for specifying the framerate for a non-raw format :/ [15:06:16] <superdump> agreed [15:26:07] * pJok blames jai [15:30:38] <jai> pJok: wut :) [15:31:28] <pJok> 16:03 < pJok> a shame ffmpeg doesn't support -r for specifying the framerate for a non-raw format :/ [15:31:53] <kshishkov> blame demuxers setting it [15:32:34] <av500> option could override it :) [15:32:47] <merbzt> av500: add it to the small task page [15:32:56] <av500> or send a patch? :) [15:33:23] <merbzt> that is an option also [15:34:11] <av500> override per default? [15:34:17] <kshishkov> or better yet, add some feature to apply options _after_ everything was set up but before decoding start [15:34:29] <av500> or new option -r_i_mean_it [15:34:32] <kshishkov> so you can totally override crappy settings in AVI for example [16:09:27] <jai> j0sh: good work so far :) [16:09:38] <j0sh> thanks [16:12:50] <kshishkov> what work? [16:13:36] <jai> theora depayloader [16:14:02] <kshishkov> ah [16:14:11] <wbs> j0sh: yeah, it looks quite good :-) [16:14:24] <wbs> j0sh: care to make a payloader, too, to keep things symmetric? :-) [16:14:31] <wbs> what gsoc task were you aiming at, btw? [16:15:22] <kshishkov> wbs: any position on replacing lavf rtmp proto with rtmpdump? [16:16:55] <wbs> kshishkov: well, if it's easy to compile, it's ok for me... but librtmp isn't generally packaged in distros yet afaik [16:17:20] <kshishkov> well, it will be outdated even before release [16:17:26] <wbs> true [16:17:29] <kshishkov> RTMP is too mutable [16:18:07] <j0sh> wbs, i was thinking rtsp [16:18:23] <wbs> j0sh: ok, what more specifically? [16:18:31] <wbs> (haven't read the gsoc page for a while) [16:18:35] <BBB> there's a general rtsp task [16:18:42] <wbs> ah, ok [16:18:42] <j0sh> minor improvements, looks like [16:18:45] <BBB> implement several missing rtp depayloaders [16:18:51] <BBB> add http transport support (apple) [16:18:57] <wbs> ah [16:19:04] <BBB> maybe port vlc to use ffmpeg's rtsp stack [16:19:09] <wbs> bbl, but please continue the discussion :-) [16:19:12] <BBB> (as primary/default, over others) [16:19:59] <j0sh> that sounds good, i could do a theora payloader too as wbs suggested [16:20:41] <BBB> it's really up to you [16:20:44] <BBB> the task is relatively free [16:20:51] <BBB> I'd recommend that you don't make it too small [16:20:59] <BBB> so don't say "I'll implement 3 depayloaders and 1 payloader" [16:21:21] <BBB> make it a bigger-picture thing, so something that you could hopefully grow into, if you're for example interested in staying on and continuing to work on it after the end of GSoC [16:21:53] <BBB> hence the VLC task (which would really pu you in between the two projects, could be interesting) and also the apple/http transport, which might also mean you have to implement the currently-missing x-qt/x-quicktime payload [16:21:58] <j0sh> yeah i would like to keep contributing.. the gsoc tasks sound ambitious enough [16:22:09] <BBB> I wrote a patch for that once but it's a little dusty [16:22:17] <j0sh> although i havent used ffmpeg's rtsp enough to have an idea of what else could to be done [16:22:42] <kshishkov> j0sh: in previous years some people managed to do them, so mentors just raised level a bit [16:22:57] <kshishkov> s/to do/to complete in time/ [16:23:25] <j0sh> so the goal is make it hard enough not to finish [16:23:46] <j0sh> so th students will stick around and continue contributing? ;) [16:23:49] <mru> the goal is to have a moving goal [16:23:55] <kshishkov> gsoc is only for summer, FFmpeg is for life ;) [16:24:22] <j0sh> heh [16:25:48] <kshishkov> for example, one guy here failed his first task, then completed task from another guy and stayed here as a developer [16:26:07] <kshishkov> or look at jai [16:26:25] <kshishkov> started with gsoc two? years ago, still here [16:26:26] <j0sh> yeah i failed to optimize h264, michael send out an email about low hanging h264 fruits [16:26:44] <mru> low is a relative measure [16:26:49] <kshishkov> heh, those are low-hanging coconuts [16:26:59] <kshishkov> (carried by laden African swallow) [16:27:55] <j0sh> heh oh well, i still learned from it... i could post what i have for h264 on the ML in case someone else wants to pick it up [16:28:20] <j0sh> the problem was the CRCs are off, otherwise videos decode fine [16:28:31] <jai> kshishkov: heh [16:29:37] <jai> j0sh: how much speedup are we talking? [16:29:47] <kshishkov> j0sh: wrong CRC means you've screwed something [16:30:03] <j0sh> yeah, i didnt benchmark yet caus the crcs weren't perfect [16:30:44] <j0sh> i was working on was for 16x8 and 8x16 temporal direct prediction, btw [16:33:10] <j0sh> BBB, is "-vcodec copy" supposed to work when decoding from rtsp? it's not doing anything for me, just hangs [16:33:32] <BBB> not sure [16:33:33] <BBB> .. [16:33:38] <BBB> does it work for theora files? [16:33:55] <jai> if it doesnt then its a bug :) [16:33:56] <j0sh> no, it actually gets sent through libtheora and re-encodes [16:34:13] <j0sh> (i think) [16:35:17] <BBB> that would be surprising [16:35:18] <BBB> and a bug [16:35:26] <gangil> merbzt: Hi , did I list the steps correctly in the mail I sent you after the discussion ? [16:35:28] <BBB> btu sounds like a bug [16:35:41] <BBB> feel free to submit an issue tracker entry for now [16:35:50] <merbzt> gangil: yes, I forgot to reply [16:35:55] <BBB> I have some other stuff to do so can't look at it right now [16:36:00] <BBB> GSoC is on the homepage now [16:36:07] <merbzt> gangil: before you do anything. talk to BBB and kostya [16:36:20] <merbzt> will save you a few days of work :) [16:36:55] <gangil> merbzt: sure :) [16:37:02] <BBB> talk to kostya ;) [16:37:07] <BBB> he knows more than me [16:37:12] <j0sh> BBB, alright will submit as a bug, will also try to investigate once the depayloader is done [16:37:13] <kshishkov> merbzt: and actually it's they who save me days of work :) [16:37:16] <BBB> in fact, he's straight scary [16:37:40] <BBB> j0sh: I'll review the patch later today, poke me if I haven't done it in 2-3hrs [16:37:54] <j0sh> will do [16:39:31] <gangil> is kostya in the channel right now ? (just wanted to know , I dont see anyone by this nick :-/) [16:39:49] <jai> kostya == kshishkov [16:40:35] <gangil> ah! sorry didnt know that :) [16:41:04] <kshishkov> I have some others names too ;) [16:41:15] <andoma> gangil: no! We must ban you from this channel for all time now! [16:41:27] <lu_zero> uhm [16:41:30] <lu_zero> now I'm around [16:41:47] <gangil> andoma: ? [16:42:17] <mru> /ban gangil <-- like that [16:42:18] <jai> your sarcasm detector needs patching :) [16:42:34] <BBB> lu_zero, you should review that rtsp patch [16:43:10] <kshishkov> jai: maybe it was turned off because of constant blinking [16:43:26] <jai> heh [16:43:51] <j0sh> BBB, lu_zero: i have a new one coming shortly [16:44:17] <BBB> so I shouldn't review this one? [16:44:19] <BBB> I'll do it anyway [16:44:22] <BBB> give me a sec [16:44:37] <merbzt> gangil: valgrind with callgrid might be usable to find out what functions are called in a binary [16:45:33] <j0sh> BBB, alright, i addressed most of the issues that were mentioned [16:50:57] * BBB goes for lunch [16:50:58] <BBB> review sent [16:52:22] <lu_zero> BBB: the website doesn't show much [16:52:27] <lu_zero> or I'm mislead? [16:52:30] <BBB> ? [16:52:40] <BBB> which? [16:53:26] <lu_zero> the gsoc one [16:53:59] <BBB> link? [16:54:07] <lu_zero> I cannot register anyway [16:54:34] <BBB> http://socghop.appspot.com/gsoc/org/apply_mentor/google/gsoc2010 [16:54:57] <lu_zero> where is that link? [16:55:05] <lu_zero> found [16:55:09] <lu_zero> last one ... [16:56:12] <lu_zero> done =E [16:56:32] <lu_zero> BBB: do you have an rtsp url that redirects? [16:56:44] * lu_zero doesn't recall which was the one he was using to test stuff [16:56:50] <BBB> no [17:44:44] <j0sh> is "if(!avfunc(..))" an effective catchall for averror? [17:49:03] <j0sh> nvm [17:53:25] <CIA-92> libswscale: cehoyos * r30934 /trunk/libswscale/ (utils.c swscale.c): [17:53:25] <CIA-92> libswscale: Extend the generic path of the yuv2rgb converter with support for rgb444 [17:53:25] <CIA-92> libswscale: output format. [17:53:25] <CIA-92> libswscale: Patch by Janusz Krzysztofik, jkrzyszt A tis D icnet D pl [17:53:26] <CIA-92> ffmpeg: stefano * r22586 /trunk/ (13 files in 4 dirs): [17:53:26] <CIA-92> ffmpeg: Add some ad-hoc tests for libavfilter. [17:53:39] <CIA-92> ffmpeg: A patched version of ffmpeg supporting video filters is required for [17:53:39] <CIA-92> ffmpeg: getting this working; thus make lavfitest is supposed to work only in [17:53:39] <CIA-92> ffmpeg: the libavfilter repository for now. [17:54:04] <elenril> what's keeping lavfi from getting merged? [17:55:48] <mru> you [17:56:39] * elenril throws http://tvtropes.org/pmwiki/pmwiki.php/Main/InsaneTrollLogic at mru [17:57:36] <kierank> throw it as xiph as well [17:57:44] <kierank> at* [18:07:36] <jai> poor xiph [18:31:34] <j0sh> BBB, im looking at using the url_dyn_buf stuff... im wondering if it's more overhead because we're not reusing the buffer space after each packet? [18:31:48] <BBB> j0sh: we can optimize dyn_buf for that later [18:32:00] <BBB> the amount of code needed will get smaller [18:32:30] <j0sh> ok [18:32:43] <BBB> in fact, we could make that part of your SoC project if you like [18:32:54] <BBB> again, up to you, millions of possibilities [18:34:12] <j0sh> alright cool [18:35:08] <elenril> do i need to bump anything when adding a new public func? [18:36:00] <kshishkov> minor version IIRC [18:37:48] <jai> yep [18:38:00] <jai> elenril: moar metadata i guess [18:39:40] <elenril> no, chapters [18:39:56] <elenril> otoh chapters are probably metadata too [18:41:10] * elenril should learn something about video coding [18:41:47] <kierank> write me an api for per packet metadata ;) [18:42:19] <elenril> why would you need something like that [18:42:45] <kierank> because dolby e has per packet metadata [18:43:01] <elenril> "this packet's name is Marisa and that other one is Alice"? [18:43:02] <jai> wow, thats insane [18:43:45] <jai> elenril: and we lost Bob on the wire [18:43:47] <kshishkov> it's not metadata, it's packet extradata :| [18:43:49] <elenril> kierank: can't you just ignore it? [18:44:12] <kshishkov> he can [18:44:21] <kierank> what's the difference between metadata and extradata? [18:44:30] <kierank> but that data is fundamental to the foramt [18:44:39] <kierank> format* [18:45:54] <kshishkov> extradata is essential, metadata is just some silly descriptions of data [18:47:15] * elenril is deeply hurt [18:47:32] <kierank> then by that definition it's metadata in dobly e [18:47:34] <kierank> dolby* [18:47:59] <kshishkov> no, it's decoder hints [18:48:40] <kierank> you can decode the audio without it [18:48:49] <kierank> it's hints for the encoder afterwards [18:49:05] <kshishkov> it's part of bitstream [18:49:37] <kshishkov> just ignore it as our AC3 decoder does [18:50:14] <kierank> it's an half the format's use case imo. it would be like decoding video without chroma [18:50:46] <kshishkov> for me it's like cake without GLaDOS [18:51:29] <elenril> <obvious statement about cake's existence here> [18:52:42] <kshishkov> kierank: it's useless when data is processed. And for specific case you may try to write bitstream filter e_to_3 [18:53:31] <kierank> it's not useless if you were using dolby e in the real-world [18:54:00] <kierank> and dolby e doesn't have to go to ac3, it can go to aac or he-aac [18:54:19] <kshishkov> oh yeah, store that data in AAC bitstream! [18:54:35] <kierank> that is what dolby have done with dolby pulse [18:55:51] * kshishkov is probably glad to not hear about it [19:00:36] * elenril wonders why av_rescale_q(INT64_MAX) returns a negative number [19:01:53] <kshishkov> input was not positive? [19:02:07] <elenril> INT64_MAX [19:02:07] <kshishkov> look at the code [19:03:03] <kshishkov> probably it overflows in rescaling [19:03:33] <elenril> don't av_rescale_* funcs exist to avoid that? [19:04:01] <kshishkov> what are other inputs? [19:04:24] <elenril> from miliseconds to nanoseconds [19:04:49] <elenril> yeah, it overflows [19:04:59] <Dark_Shikari> under what conditions will configure generate .pc files? [19:05:00] <elenril> but i'd expect it to handle that [19:05:01] <Dark_Shikari> I can't make it do it [19:07:10] <kshishkov> --enable-shared? [19:07:30] <Dark_Shikari> ok, so it's generating them but I can't figure out where it's installing them [19:07:38] <Dark_Shikari> INSTALL libavformat/libavformat.pc [19:07:42] <Dark_Shikari> what does this do? I have no idea. [19:07:50] <Dark_Shikari> it certainly doesn't put them in /usr/share/pkgconfig [19:07:57] <kshishkov> look at prefix [19:07:58] <janneg> make V=1 install [19:08:08] <kshishkov> probably /usr/local/share/pkgconfig [19:08:40] <Dark_Shikari> ah cool, V=1 [19:23:37] * peloverde wonders why the math in the PS spec is informal to the point of ambiguity [19:24:01] <CIA-92> ffmpeg: stefano * r22586 /trunk/ (13 files in 4 dirs): [19:24:01] <CIA-92> ffmpeg: Add some ad-hoc tests for libavfilter. [19:24:01] <CIA-92> ffmpeg: A patched version of ffmpeg supporting video filters is required for [19:24:01] <CIA-92> ffmpeg: getting this working; thus make lavfitest is supposed to work only in [19:24:01] <CIA-92> ffmpeg: the libavfilter repository for now. [19:24:02] <CIA-92> ffmpeg: stefano * r22587 /trunk/tests/lavfi-regression.sh: [19:24:03] <CIA-92> ffmpeg: Make ad-hoc lavfi tests use random values for the slice height used [19:24:03] <CIA-92> ffmpeg: per each frame, useful for testing slicification. [19:24:04] <CIA-92> ffmpeg: stefano * r22588 /trunk/ (doc/ffplay-doc.texi ffplay.c): [19:24:04] <CIA-92> ffmpeg: Add a -window_title option, which sets the FFplay window title. [19:24:05] <CIA-92> ffmpeg: Patch by Robert Kr?ger "krueger ET signal7 DOT de". [19:24:05] <CIA-92> ffmpeg: stefano * r22589 /trunk/cmdutils.c: [19:24:06] <CIA-92> ffmpeg: Remove printing of frame sizes and frame rate abbreviations from [19:24:06] <CIA-92> ffmpeg: show_protocols(). [19:24:07] <CIA-92> ffmpeg: The list of abbreviations is both outdated and out of context. [19:24:08] <CIA-92> ffmpeg: stefano * r22590 /trunk/libavformat/aviobuf.c: [19:24:20] <CIA-92> ffmpeg: Patch by Janusz Krzysztofik foo=zyszt <jkr$foo(a)tis.icnet.pl>. [19:24:21] <CIA-92> ffmpeg: benoit * r22598 /trunk/ffmpeg.c: [19:24:21] <CIA-92> ffmpeg: ffmpeg.c: copy chapters by default. [19:24:21] <CIA-92> ffmpeg: Patch by Anton Khirnov wyskas gmail com [19:24:22] <CIA-92> ffmpeg: mru * r22599 /trunk/ffmpeg.c: Register atexit handler only when needed [19:25:55] <CIA-92> libswscale: cehoyos * r30934 /trunk/libswscale/ (utils.c swscale.c): [19:25:56] <CIA-92> libswscale: Extend the generic path of the yuv2rgb converter with support for rgb444 [19:25:56] <CIA-92> libswscale: output format. [19:25:56] <CIA-92> libswscale: Patch by Janusz Krzysztofik, jkrzyszt A tis D icnet D pl [19:25:56] <CIA-92> libswscale: diego * r30937 /trunk/libswscale/swscale.c: [19:25:56] <CIA-92> libswscale: Check whether COMPILE_ALTIVEC is defined, not if it is set to a 0/1 value. [19:25:57] <CIA-92> libswscale: COMPILE_ALTIVEC is never set to 1, it is just #defined. [19:25:57] <CIA-92> libswscale: diego * r30938 /trunk/libswscale/swscale_template.c: Replace wrong condition name in #endif comment by correct instance. [19:29:11] <kierank> peloverde: because it's a spec [19:29:29] <kierank> on the one hand it tries to define everything ever so precisely yet in other situations just messes it up [19:38:12] <j0sh> BBB, about the dyn_url stuff... when i do a put_buffer, it flushes to *somewhere* after a certain size. how do i recover my original data? [19:40:41] <peloverde> Reddit boggles my mind... what does "Mozilla: Stick to Your Ideals, Shun H.264" have to do with Linux? [19:41:24] <elenril> obviously all linux users are freetards who hate h.264 [19:42:00] <j0sh> BBB, close_dyn_buf? [19:43:53] <iive> elenril: i guess you are not linux user [19:44:31] <elenril> iive: http://tvtropes.org/pmwiki/pmwiki.php/Main/SarcasmFailure [19:44:44] <peloverde> I use linux and I think a few others here do, anyway codec choice for HTML5 seems completely disjoint form the topic of "Linux" [19:50:38] <iive> yep, don't forget that the best h264 decoder and the best x264 encoder are free GPL native linux programs, that also work in other OS-es [19:56:54] <elenril> decoder? i hear coreavc is much faster than ffh264 [19:58:52] <BBB> j0sh: yes [20:00:47] <iive> elenril: old news :P [20:01:30] <j0sh> BBB, yup got it... figures, after an hour of figuring out the dyn_buf api, i got it 30 seconds after asking :) [20:02:26] <j0sh> BBB, im also going to submit a separate patch in the same thread refactoring out similarities with vorbis, that OK? [20:02:46] <Kovensky> <@Dark_Shikari> it certainly doesn't put them in /usr/share/pkgconfig <@kshishkov> probably /usr/local/share/pkgconfig <-- $prefix/lib/pkgconfig is the correct path [20:03:27] <Kovensky> <iive> yep, don't forget that the best h264 decoder and the best x264 encoder are free GPL native linux programs, that also work in other OS-es <-- x264 encodes x264 video? :o [20:04:08] <pJok> x264 is the new format [20:04:10] <iive> Kovensky: don't twist my twist. [20:04:19] <pJok> its better than h264 because it has an x instead of an h [20:04:53] <jai> pJok: you should be in marketing ;) [20:05:23] <pJok> jai, i shouldn't... [20:05:40] <pJok> i would just stab the other marketing people with pencils [20:08:23] <jai> :) [20:10:02] <BBB> j0sh: of corudse [20:10:15] <BBB> j0sh: I would've been ok with that afterwards also, but if you want to do it before, that's great [20:10:26] <BBB> anything decreasing amount of code is ok [20:10:52] <j0sh> is there private common code somewhere? utils.c is all public [20:11:07] <BBB> anything ff_* is private [20:11:20] <BBB> you can make it rtp_xiph.c if you want [20:11:51] <j0sh> ok [20:13:52] <hyc1> what is the point to keeping the old rtmp implementation? it's incomplete. When is it ever going to be useful to have it around at the same time as the new one? [20:19:30] <thresh> grievening [20:29:43] <j0sh> BBB, looks like the vorbis refactoring will have to wait until the weekend, but i'm submitting an updated patch shortly [20:42:58] <Compn> hyc : ffmpeg rtmp works with red5 or whatever it was tested with, so it does work... [20:49:58] <hyc> Compn: ok [20:50:08] <hyc> still, it hangs on some other servers [20:50:55] <hyc> if it wasreliably usable, that'd be great. but since it's not, and it's not being actively maintained, and it's missing features... [20:51:32] <hyc> it's not like I have any particular reason to be pushy, I just don't like to wait [20:52:42] <Compn> well michael said he wanted native rtmp to stick around if librtmp was added [20:52:49] <Compn> so best to agree with him :) [20:53:01] <j0sh> wbs, BBB, just sent a updated patch to the ML. thanks for the help! [20:53:08] <Compn> if you wanted it to be added that is [20:53:30] <hyc> Compn: yeah, fine. [20:53:51] <hyc> I think I already made my point. it's only going to cause confusion. [20:54:09] <Compn> quite [20:58:08] <hyc> meanwhile I've got it working in xbmc now [20:58:30] <hyc> xbmc also has libavformat. could cut down some size by just using a single implementation [20:59:24] <hyc> but the API still needs to be extended to handle time-based seeks better [20:59:39] <hyc> xbmc's native code does that OK [20:59:51] <hyc> even though they use the lavf flv demux [20:59:59] <hyc> still trying to figure out why that works... [21:02:09] <BBB> hyc: because we prefer having something in? [21:02:41] <BBB> and inactive maintenance is a chance for you to contribute to one of the greatest free software projects :) [21:04:18] <hyc> BBB: I've already contributed [21:04:56] <hyc> and I'd rather spend my time working on expanding the feature set (e.g., getting seek working consistently) [21:05:06] <hyc> than rehashing old code [21:05:30] <BBB> like I said before, ffmpeg is not a libXY wrapper toolkit [21:05:44] <BBB> ffmpeg integrates multimedia functionality [21:05:51] <BBB> submit rtmpe into ffmpeg [21:06:18] <hyc> BBB: adding rtmpe to the existing ffmpeg code would be a waste of time [21:06:28] <bcoudurier> too bad [21:06:47] <bcoudurier> I agree with michael [21:07:00] <hyc> librtmp is already a complete superset of the existing code [21:07:00] <bcoudurier> and I'd prefer the native code to be improved [21:07:11] <bcoudurier> https would be a nice feature also [21:07:30] <bcoudurier> we do not like external dependencies much [21:07:42] <hyc> you can all do what you prefer. but clearly the lead maintainer isn't spending any time on it. [21:07:51] <bcoudurier> it's a nightmare for users [21:08:03] <bcoudurier> hopefully someone will take over [21:08:08] <bcoudurier> why don't you ? [21:08:19] <bcoudurier> it's a great opportunity to understand rtmpe [21:08:21] <hyc> you have no choice - you need an external TLS library. unless you want to write that too. [21:08:51] <hyc> I already understand rtmpe inside and out. probably better than anyone else in the free software community. [21:09:28] <hyc> as for external libs - rtmpdump is hosted on the same svn as ffmpeg and mplayer. just make it an external SVN reference. users will never know the difference. [21:09:38] <hyc> except that it works with more sites. [21:09:38] <bcoudurier> oh is librtmp your lib ? [21:09:54] <hyc> yes [21:10:11] <bcoudurier> I understand better [21:10:39] <bcoudurier> good work btw [21:10:44] <hyc> ;) [21:12:37] <andoma> hyc: path to the repo? [21:12:45] * BBB thinks hyc is an arrogant piece of shit that needs to grow up [21:12:53] <BBB> good luck with libXY [21:13:09] <BBB> I can see 5 yrs from now I have to ask a gsoc student to integrate the dead project into ffmpeg, just like with libmms now [21:13:10] <BBB> great [21:13:12] <BBB> just great [21:13:26] <hyc> BBB: you can ask Compn how much labor / research has gone into it [21:13:49] <hyc> andoma: svn.mplayerhq.hu/rtmpdump/trunk/librtmp [21:13:55] <andoma> hyc: thanks [21:14:21] <hyc> BBB: compare that to how much maintenance has gone into ffmpeg rtmp [21:14:31] <hyc> and you tell me which one is going to be dead in 5 years. [21:14:46] <bcoudurier> I hope ffmpeg won't be [21:15:21] <hyc> bcoudurier: I don't mean ffmpeg as a whole. [21:15:31] <hyc> just looking at the rate of development of ffmpeg rtmp. [21:15:42] <bcoudurier> besides rtmp code is kinda new [21:16:21] <bcoudurier> and it seems some users are actually using it, I don't know if it is that much though [21:17:05] <hyc> in the time since we entered mplayerhq SVN till now (~Sep 2009) we've done more work to stabilize it, extend it,make it portable. [21:18:55] <bcoudurier> that's great, I wish it would be the same for native rtmp and I understand you don't want to improve the native one [21:19:37] <hyc> and it's great that users are using the native one [21:19:48] <hyc> again, switching doesn't lose them anything. it only gives them more. [21:21:39] <hyc> anyway, that argument is over. if they want to keep the old code in place, that's fine, not my problem. [21:21:50] <Dark_Shikari> ffmepg is all about leaving around old code that sucks [21:21:54] <Dark_Shikari> see vorbisenc ;) [21:22:29] <bcoudurier> encoding is different [21:22:38] <bcoudurier> and code sucking != code missing features [21:22:42] <Dark_Shikari> True. [21:23:02] <bcoudurier> so instead of bashing ffmpeg why don't you go on doing something better ? [21:23:25] <bcoudurier> like coding _on_ ffmpeg since you claim to be a ffmpeg developer [21:24:10] <hyc> bcoudurier: I have a task in mind already - getting time-based seek working consistently. I said that already [21:24:34] <hyc> but there's no point in adding frills to an inadequate foundation. [21:26:37] <hyc> I'm not bashing - just pointing out the obvious. users will get confused if they some rtmp streams work and some don't, because there are two "parallel" implementations active at the same time, and one doesn't implement all the security features of the other. [21:34:32] <BBB> hyc: I'm seeing the situation in 5 yrs where the world has moved away from rtmp, like MS moves away from mms, and everyone uses new techniques (most likely modified versions of rtsp, maybe even straight http) through html5 (MS did that also)... we'll be left with 2 dead codebases, one of which sucking more than the other, but the other not being shipped because it's obsolete anyway [21:35:06] <BBB> hyc: and people keep wondering why half of their radiostations don't work (for whatever crap reason) - we could've fixed that here, today [21:35:17] <BBB> but nobody cares about that in 5 yrs, it's history [21:39:40] <hyc> frankly, I hope that happens. I hope that in 5 years everyone is using HTML5 video and rtmp dies a well deserved death [21:39:48] <hyc> it's all crap anyway [21:41:28] <hyc> in the meantime, the two main arguments I'm hearing are both nonsense. you can't add rtmpe support without a crypto library. so if you're opposed to adding external dependencies, well, tough. [21:42:31] <hyc> and as for maintaining existing code - librtmp existed first... [21:44:20] <hyc> if you care about providing stable features, the more mature code base is naturally the better bet. [21:47:47] <bcoudurier> we agree, but we cannot reasonably refrain people from coding something new if they want to [21:48:27] <bcoudurier> for encoders quality produces will matter though [21:48:35] <bcoudurier> produced [21:49:35] <peloverde> The first google result for librtmp is a dead link [21:49:58] <hyc> http://rtmpdump.mplayerhq.hu [21:50:13] <hyc> that shouldn't be hard for the folks around here to find... [21:52:17] <thresh> what about xbmc fork? [21:52:46] <hyc> thresh: what do you mean? [21:53:31] <peloverde> If that's such a mature codebase why isn't it on the first page for "librtmp"? [21:53:37] <iive> i thought that ffmpeg rtmp effort started when rtmpdump run into legal trouble [21:54:13] <hyc> peloverde: because everyone just called it rtmpdump [21:54:25] <thresh> oh, that's google providing wrong links, sorry [21:55:03] <hyc> the rtmpdump code started from XBMC's libRTMP. [21:55:26] <hyc> then the DMCA thing hit and it got deleted from sourceforge [21:55:58] <hyc> then a couple months later the mplayer folks offered to host it [21:56:32] <hyc> so, the current rtmpdump web site is rather new and no, it's not #1 in the google results [21:57:57] <hyc> I started working on it because I was working with the guys at AlwaysInnovating to write a watch_hulu app for their Touchbook [21:58:13] <hyc> the original code was in C++ and it triggered an ARM g++ bug [21:58:27] <BBB> btw who's against a crypto library in ffmpeg? [21:58:28] <hyc> that would send it into an infinite loop while opening a connection. [21:58:42] <BBB> is libssl portable? I thought it was [21:59:09] <hyc> yes, libssl works fine on many platforms. works fine on ARM [21:59:37] <hyc> BBB: I don't know if anyone is against a crypto library in ffmpeg [21:59:58] <hyc> I see you have several of the necessary functions already in libavutil [22:00:08] <iive> BBB: we already have some crypto functions from wmv drm. check avutil. [22:00:29] <BBB> well that's one argument gone [22:00:34] <hyc> but again, it seems to me to be a better use of time to expand functionality, not just keep duplicating existing features. [22:01:02] <hyc> what's the motivation to keep adding crypto functions to libavutil? [22:01:26] <iive> hyc: when there is enough of them, we'll make avcrypt [22:01:30] <hyc> do you have a team of subject-matter experts here just chomping at the bit, waiting to write their next crypto function? [22:01:48] <bcoudurier> people like and want to [22:02:19] <BBB> hyc: anything wrong with that? [22:02:27] <BBB> oh no! we'll share code between wmv and rtmp [22:02:27] <BBB> th [22:02:35] <BBB> that must mean it's patent-encumbered [22:02:42] <BBB> they'll sue each other to death! so let's not [22:02:43] <BBB> ohwait [22:02:46] <BBB> we don't give a shit [22:04:04] <hyc> ok, let me know when you have ffmpeg tls working... [22:05:34] <iive> hyc: is that the only problem? do you need full tls functionality? [22:06:15] <hyc> iive: from what I've seen with rtmp, there are very few sites using rtmps (RTMP over SSL/TLS) [22:06:21] <hyc> so you can probably live without it [22:06:52] <hyc> but RTMPE still requires a Diffie-Hellman key exchange in the handshake [22:07:10] <hyc> and generally, code for D-H is part of TLS libraries since that is one of their possible handshakes [22:07:33] * iive checks avutil as D-H sounds familiar [22:07:48] <kierank> how is swf verification going to operate in ffmpeg? [22:07:48] <hyc> librtmp was originally written for OpenSSL, but I've adapted it to work with GnuTLS too [22:08:30] <hyc> kierank: librtmp will do the verification and maintain a cache of verify info [22:09:42] <hyc> we just append option switches to the RTMP URL [22:09:44] <hyc> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2010-March/063988.html [22:10:30] <hyc> I setup the same options in my ffmpeg patch, so ffplay would do the same [22:14:55] <iive> hyc: i don't see any commits in mplayer related to rtmp [22:15:09] <hyc> iive: uau pulled them into his git tree [22:15:31] <hyc> but if we go into ffmpeg, then most of those commits could be ignored [22:15:40] <iive> you know that would benefit only uau own fork. [22:16:27] <BBB> who is uau? [22:16:33] <hyc> yes, I see... [22:17:45] <iive> BBB: Uoti Urpala [22:18:08] <BBB> oh I see that's a flamewar subject right? [22:18:18] * BBB not very familiar with the mplayer history [22:18:20] <hyc> looks like it [22:21:10] <ramiro> BBB: mplayer started as an entry to the IOCCC. [22:21:22] <iive> well, my version is that uau didn't follow project rules. few times there was a call to be removed from project. he was kept in as viable contributor. now he doesn't contribute anything and pretends that his fork is the real mplayer. [22:21:23] <ramiro> the coding standards haven't changed since then. [22:26:18] <ramiro> hyc: what did paypal do? [22:27:39] <hyc> ramiro: they froze our account after our first donation [22:27:51] <hyc> I guess they think I'm an international terrorist money launderer [22:28:09] <hyc> (it was 10 euros) [22:28:44] <ramiro> did they give any explanation? [22:28:58] <hyc> I went back and forth with them for a week [22:29:20] <ramiro> they're assholes... they froze my account once too [22:29:22] <hyc> they said if I wanted a full explanation I would have to send them a subpoena from a judge for their documents [22:29:32] <hyc> yeah, assholes. [22:29:52] <ramiro> luckily now I can cash money to my bank account in brazil. [22:30:07] <iive> hyc: did you had money in the frozen account? [22:30:07] <ramiro> so I get it out as soon as I have enough to not pay fees =) [22:30:19] <ramiro> iive: he said 10 euros [22:30:36] <hyc> I was considering adding some PayPal Sucks logos to the page, but decided I didn't want to distract from our main mission [22:31:09] <ramiro> btw I would never trust paypay. it seems like a huge scam. [22:31:20] <ramiro> starting by the name =) [22:31:34] <hyc> in fact some of their policies are just as bad as paypal [22:31:51] <hyc> so, we'll see what happens when the next donor comes along, if we get another hassle or not [22:32:16] <hyc> but they do seem to have a lot of recommendations out there [22:34:14] <hyc> i don't expect much will come of it. I only set up the first paypal account because someone emailed the list and asked where to send donations to. we didn't have anything on the web site before that. [22:34:43] <hyc> I'm sure he'll be pleased to know that his 10 euros are locked away in paypal's bank account now. [22:35:41] <kierank> ^^ small claims court [22:36:29] <BBB> btw [22:36:38] <iive> kierank: e.g. i'm not sure my country have such thing at all. [22:36:39] <BBB> hyc, if you want to be part of the ffmpeg foundation that's fine with me [22:36:41] <BBB> we can sue for you [22:36:50] <BBB> we have good lawyers [22:39:53] <hyc> lol... for 10$ it's not worth the time [22:40:15] <hyc> but it's good to know re: the lawyers. may need them if rtmpe support moves forward. [22:40:38] <kierank> BBB: ok if I PM you about something? [22:46:56] <BBB> yes [23:35:23] <CIA-92> ffmpeg: stefano * r22600 /trunk/libavutil/error.h: Extend description for AVERROR_INVALIDDATA. [23:35:24] <CIA-92> ffmpeg: stefano * r22601 /trunk/libavutil/error.h: [23:35:24] <CIA-92> ffmpeg: Change the definition of AVERROR_INVALIDDATA at the next libavutil [23:35:24] <CIA-92> ffmpeg: major bump, using an FFmpeg specific error code rather than EINVAL, [23:35:24] <CIA-92> ffmpeg: which has a quite different semantics.

1 0

IRC log for 2010-03-18
by irc＠mansr.com 19 Mar '10

19 Mar '10

[05:43:37] <duncan__> ok [05:43:39] <duncan__> hello [05:43:50] <duncan__> question about j2k codec [06:30:47] <thresh> mourning [06:30:55] <kshishkov> whom? [06:33:36] <thresh> my whole life [06:34:22] <kshishkov> agreed [06:34:32] <kshishkov> maybe you should move to Switzerland? [06:35:46] <av500> or sealand [06:36:13] <thresh> switzerland suits me landscape-wise [06:38:56] <kshishkov> it's not all about you, someone should convince KotH that life may be not so bright [06:39:35] <pJok> god morgon :) [06:39:37] <kshishkov> I don't mind if your life becomes better though [06:39:46] <kshishkov> goda morgnar, pJok [07:15:03] <KotH> a wonderfull, beautifully sunny good morning! (modulo ukranians) [07:15:27] <kshishkov> x % 0 = ? [07:15:38] <KotH> \inf [07:16:27] <kshishkov> no, it's 0. You should've said "modulo civilised world" [07:16:50] <kshishkov> which also excludes wonderful London mornings though [07:17:05] * KotH has never seen a wonderful morning in london [07:17:30] <kshishkov> you don't like fog, smog and rain? [07:18:29] <KotH> nope, i dont [07:18:52] <kshishkov> ok, not wonderful London mornings for you either [07:18:55] <kshishkov> *no [07:22:13] <av500> kshishkov: there is no more fog in london [07:22:59] <kshishkov> never? [07:23:15] <av500> not as much as there used to be... [07:23:28] <kshishkov> it's not a pity [07:23:46] <av500> and I saw nice mornings there too :) [07:24:00] <thresh> no such thing as nice morning [07:24:09] <kshishkov> in Russia [08:23:43] <kshishkov> http://www.engrish.com//wp-content/uploads/2010/03/tiny-grass-is-dreaming.j… - it may be even funnier for mru/thresh [08:26:24] <thresh> yeah [08:28:49] <av500> http://briancrescimanno.com/2010/03/17/dear-mozilla-please-dont-kill-html5-… [08:28:53] <av500> some ppl have sense left... [08:30:49] <kshishkov> you mean those? http://openvideoalliance.org/2010/03/lets-get-video-on-wikipedia/ [08:31:33] <KotH> kshishkov: i think i'm too used to jenglish to find it that funny ^^' [08:32:07] <kshishkov> KotH: compare English and Japanese translations for example [08:32:15] <kshishkov> and Russian is most hilarious [08:32:16] <thresh> and a russian one [08:32:58] <kshishkov> it's correct though [08:33:01] <KotH> kshishkov: they match quite well :) [08:33:51] <av500> kshishkov: with the given trend of replacing written internet editorial content with blurry shaky boring yutube videos, I think it is a perfect thing for wikipedia - no more edit wars over spelling and puctuation... [08:35:49] <elenril> KotH: the correct term is engrish =p [08:36:15] <kshishkov> especially since that example is from Chinese [08:38:59] <KotH> elenril: no, engrish is what usians speak ;-) [08:39:15] <KotH> elenril: in contrast to the japanese jenglish and the german denglish [08:40:14] <kshishkov> KotH: Denglis_c_h [08:41:01] <av500> kshishkov: that still misses _a_ [08:41:24] <KotH> dänglisch? [08:41:34] * elenril throws some more utf-8 at KotH [08:41:41] <av500> well, it needs to have _d_, _a_ and _ch- [08:42:17] <KotH> chum etz! d'schwyzer chöi es ganz guets englisch [08:42:30] <kshishkov> av500: you should have roof by now [08:42:43] <av500> indeed [08:43:50] <kshishkov> av500: for some reason Ukrainian word for roof sounds the same as German one [08:44:15] <thresh> ÐºÑiiiiÑÐ°? [08:44:32] <kshishkov> ÐŽÐ°Ñ [09:13:23] <kshishkov> mate! [09:13:28] <pross-au> Hey [09:14:30] <kshishkov> what're you going to do when all multimedia from EA games can be played with FFmpeg? [09:15:38] <av500> elenril: nice! [09:16:45] <pross-au> I will join the RE-holics anonymous [09:17:14] <kshishkov> and IIRC you had only two codecs left [09:18:24] <pross-au> Your IIRC is wrong [09:18:32] <twnqx> pross-au: you could hack sane to support my scanner, should only be minor changes :P [09:21:07] <kshishkov> twnqx: a block of wood should be enough [09:32:58] <elenril> av500: it'd be nice if you could test it [09:33:27] <elenril> i'm still not sure i got timestamp transformations right [09:34:28] <av500> that would assume I would know how to use ffmpeg with more than one in and out file... :) [09:34:48] <kshishkov> consequently! [09:35:29] <kshishkov> ffmpeg -i in1 -i in2 ... out1; ffmpeg -i in1 -i in2 ... out2 [13:22:21] <sh311> jai: hi this is naufal. can i pm you? [13:41:18] <twnqx> janneg: how i get the resulting pics to you? :P [13:43:44] <peloverde> BBB, I can look at that stuff today [13:43:52] <BBB> yay [13:43:58] <BBB> you want me to send it per email? [13:44:09] <peloverde> yeah, that will work [13:45:02] <BBB> sent [13:46:50] <dgt84> Anyone know if new libavfilter filters are welcome? I see a lot are still stuck in the SoC repo. I wrote a quick one to modify brightness yesterday to try and learn how it all works and am porting MPlayer's vf_unsharp for a project. [13:47:59] <KotH> if you are porting over filters, make sure you either make them GPL or rewrite them from scratch and make them LGPL (which is preferred) [13:48:32] <KotH> or ask the orignal author whether he minds if you use his code as lgpl [13:50:58] <Dark_Shikari> There are tons of avisynth filters you can probably port [13:51:18] <dgt84> KotH, looks like the original is GPL 2+, but I can email him and see what he says. I'm not sure about a reimplementation, that unsharp filter is a pretty close 1:1 implementation of a paper on the subject, same variables and everything [13:52:56] <merbzt> dgt84: post to ffmpeg-dev [13:53:10] <dgt84> afaict this is the paper: https://docs.google.com/viewer?url=http://www.engin.umd.umich.edu/~jwvm/ece… [13:53:10] <merbzt> stefano and michael will probanbly care [13:54:50] <KotH> dgt84: it doesnt matter on what it is based, copyright still applies [13:55:05] <thresh> __gb__: could i poke you with some patches for libva-sds? [13:57:45] <dgt84> KotH, yeah, will contact the author then [13:58:05] <dgt84> merbzt, alright, will go get flamed [13:58:13] <merbzt> :) [13:58:39] <dgt84> Dark_Shikari, if you have any avisynth filters in mind let me know, I'll throw the list on the wiki or something and then others will know what is worth porting over. [13:59:02] <Dark_Shikari> dgt84: the real problem is a lot of the best "filters" are scripts involving other filters [13:59:10] <Dark_Shikari> e.g. masktools, mvtools, all combined to make a big fancy filter [13:59:12] <justlooking> KotH, your saying you can copyright an algorithm in some countrys ? [13:59:15] <Dark_Shikari> like tempgaussmc, the world's best deinterlacer [13:59:29] <twnqx> s/best/best and slowest/ [13:59:31] <KotH> justlooking: not the algorithm, but its implementation [13:59:48] <KotH> justlooking: if you base your implementation on another, you have to abide copyright [14:00:07] <KotH> justlooking: if you base your implementation only on the description of the algorithm, copyright doesnt apply [14:02:53] <dgt84> Dark_Shikari, ah yeah, I've seen some of the more complex things. I think I used mvtools to deshake some video a while back and it was fairly complicated. I'll probably only be paid to port sharpening, deinterlacer like yadif, and maybe some postproc stuff. The rest I'd have to do outside of work. [14:04:41] <twnqx> ugh [14:04:50] <twnqx> i just stab() the video in such cases :P [14:05:10] * KotH stabs some randome mere mortals in the channel [14:05:51] <siretart`> sorry, german only, but did you already notice this: http://www.heise.de/newsticker/meldung/Aldi-und-Lidl-wegen-MPEG-Patentverle… [14:06:28] <siretart`> english: the supermarkets 'aldi' and 'lidl' (both *very* polular in german) are being sued by MPEGLA [14:06:40] <twnqx> could be interesting [14:06:46] <twnqx> since software patents are not legal in .de [14:06:47] <twnqx> :> [14:06:50] <dgt84> oh noes, I actually bought a computer at Aldi Sued once [14:07:04] * twnqx reports dgt84 to the MPEGLA [14:07:16] <dgt84> :-P [14:08:37] <siretart`> they are being sued for selling dvd players, btw. [14:09:15] <KotH> siretart`: wtf? [14:09:17] <twnqx> among other things [14:09:22] <KotH> siretart`: do you know how the medion case ended? [14:09:25] <twnqx> no mpeg2 license. [14:16:46] <siretart`> KotH: no idea [14:17:08] <KotH> siretart`: would be interesting to know [14:17:15] <siretart`> indeed [14:17:54] <J_Darnley> Were medion sued too? For DVD players? [14:18:27] <siretart`> J_Darnley: there is not much practical difference between aldi and medion in this case [14:20:58] <J_Darnley> Right. That explains why aldi has so much medion-branded stuff [14:27:34] <janneg> twnqx: if there is web/ftp server running tar them without compression and I'll download them. otherwise I'll set a ftp server up [14:27:35] <siretart`> it's their "house brand" after all [14:28:33] <kshishkov> siretart`: knowing Lidl they must sell some Chinese players (i.e. no licenses whatsoever) [14:33:35] <twnqx> janneg: link in pm [14:42:42] <peloverde> BBB: I your description seems correct [14:42:44] <__gb__> thresh, sure [14:44:38] <BBB> peloverde: I peeked repeatedly at the paper to make sure I had it correct [14:44:42] <BBB> ;) [14:44:47] <kshishkov> good [14:44:54] <BBB> but the technique makes sense now that I see theory + implementation next to each other [14:45:11] <BBB> I'll submit later today I guess [14:45:36] <peloverde> It's pretty intense, especially considering you have no formal background in signals :) [14:45:54] <BBB> that's why I'm doing this :) [14:45:57] <BBB> I want to learn [14:46:15] <kshishkov> peloverde: you and Swedes may be the only guys who have such formal background [14:46:26] <BBB> kshishkov: how did you learn? [14:46:32] <BBB> by doing, by teaching or something else? [14:47:13] <kshishkov> my teaching skills are nonexistent and nobody at the university bothered to tell us anything about it [14:47:16] <peloverde> you may want to reference the paper somewhere in the comments [14:47:58] <kshishkov> BBB: so probably it was doing and some papers I found and read (and maybe even understood one or two of them) [14:51:33] <BBB> kshishkov: in ida, if I know a particular register that holds the main structure ("this") in a function, how can I tell it to use a particular "structure" for this? [14:51:41] <BBB> I'd like to make better use of ida but it's a bit incomprehensible [14:52:09] <kshishkov> right-click menu and select "structure pointer" [14:53:08] <BBB> I don't have that, can I use edit->struct var? [14:53:21] <BBB> looks like it does what I awnt [14:53:48] <kshishkov> probably, what I said works only in decompiled code [14:54:05] <kshishkov> I've never bothered with structures in plain asm [15:00:29] <BBB> bleh, the whole thing is crapping out and has no undo [15:00:30] <BBB> darnit [15:16:29] <av500> siretart`: yes, had much fun in the heise comments thread today... [15:20:13] <ramiro> BBB: ctrl+w every time you do something important. close (don't save or pack) and reopen when you screw up. [15:20:38] <BBB> too late :) [15:20:48] * BBB suddenly dislikes ida [15:21:35] <jai> BBB: you need to spend some more time with it :) [15:21:57] <BBB> I suppose [15:22:23] <ramiro> it takes a couple of lost hours of work to get used to it =) [15:23:35] <jai> hehe [15:23:39] <BBB> it's like MS Word in college [15:23:47] <BBB> \o/ ... [15:23:57] <av500> U had to learn word in college? [15:24:11] <jai> we had to learn wordstar in school iirc [15:24:25] <av500> we had to learn words iirc [15:25:02] <kshishkov> BBB: but you have "don't save database" flag during closing [15:25:24] <BBB> I'll get the hang of this [15:25:31] <BBB> I now know I hate the struct defs in ida [15:25:34] <BBB> so not going to use that [15:25:39] <kshishkov> jai: we had to learn both some Soviet word processor for DOS and Word [15:25:42] <BBB> it made the code a struct instead of the register a pointer to struct [15:25:51] <ramiro> BBB: I hate them too, but what are you going to use instead? [15:25:54] <BBB> I couldn't undo that [15:26:03] <astrange> i found some ida plugin that reads C files for struct definitions [15:26:12] <BBB> ramiro: gdb? ;) [15:26:17] <astrange> but it only sort of worked [15:26:20] <kierank> ollydbg... [15:28:19] <jai> the olly disasm engine isnt nearly that good [15:28:27] <kshishkov> objdump :) [15:31:52] <BBB> now I'm trying to create a struct with 10kB in it [15:31:56] <BBB> and default all to an int [15:31:58] <BBB> this is so painful [15:32:24] <merbzt> why not an array ? [15:32:55] <BBB> I want to give each individual names [15:33:04] <BBB> like val_000 could be a counter, while val_004 could be a function pointer [15:33:05] <BBB> etc. [15:33:28] <merbzt> 10kb of struct members [15:33:36] <merbzt> I don't think so [15:33:46] <merbzt> must be some arrays in there [15:33:48] <BBB> part of it is likely an array [15:33:52] <BBB> but not all of it [15:34:16] <BBB> I guess you're saying "start with a array", "add individual members as you figure them out"? [15:34:46] <merbzt> something like that [15:35:05] <merbzt> but you can read structs from h files [15:35:23] <merbzt> and those you can generate [15:36:56] <kshishkov> does anyone know an easy way to find decoder function in DShow/DMO? [15:38:09] <BBB> do a call tree and find the one at the base of most calls? [15:38:17] <merbzt> I would like to have a tool that would trap call instruction and then generate a code coverage report from it [15:38:30] <astrange> valgrind --tool=callgrind wine ... [15:38:45] <merbzt> neat [15:38:58] <astrange> well, if it works [15:39:01] <kshishkov> BBB: no, it's all COM - i.e. factories, function pointers embedded devil knows where and IIDs [15:39:32] <merbzt> astrange: does it work with mplayer and dlls ? [15:40:19] <kshishkov> it should [15:40:53] <merbzt> that would be awesome [15:40:58] <merbzt> gotta try it at home [15:41:13] <kshishkov> gotta try it in a minute [15:41:28] <mru> what are you guys REing? [15:41:34] <merbzt> everything [15:41:37] <av500> VP8 [15:41:51] <mru> I know everything is the ultimate goal [15:42:08] <mru> and vp8 doesn't exist... [15:42:17] * BBB is having a quick look at wvp2 [15:42:49] <mru> but vp7 exists [15:42:49] <kshishkov> mru: but it's true - I try to RE everything and just pick what REs easier [15:43:10] <mru> wouldn't it be cool if we had an opensource decoder before google _maybe_ releases it [15:43:45] <BBB> what if google is also doing that? [15:43:50] <BBB> would be a waste of time [15:44:14] <astrange> apple icodec and prores shouldn' [15:44:16] <kshishkov> can somebody ask Google for TrueMotion 2X? [15:44:17] <mru> we'd have to RE whatever code they release anyway [15:44:18] <astrange> t be too hard to RE [15:44:31] <kshishkov> astrange: why haven't you done them yet? [15:44:56] <kshishkov> I verified by myself - AIC is easy to RE [15:45:18] <astrange> hmm i made a struct definition file for it then lost it [15:46:13] <kshishkov> and I made http://wiki.multimedia.cx/index.php?title=Apple_Intermediate_Codec and then lost interest [15:49:06] <kshishkov> callgrind works fine [15:49:11] <kshishkov> with MPlayer and dlls [15:49:44] <merbzt> can you show a report it generates ? [15:50:12] <kshishkov> it's text file with functions and calls [15:50:31] <merbzt> can you post a link to one ? [15:50:32] <kshishkov> I see one small flaw though - for DLL funcs it does not print function addresses [15:50:46] <merbzt> :/ ie no use [15:51:29] <kshishkov> could be, I just haven't converted it into something more useful [15:51:40] <av500> http://www.catonmat.net/blog/top-ten-one-liners-from-commandlinefu-explaine… ffmpeg is #10... [15:52:36] <merbzt> KCachegrind should be able to visuausize it well [15:54:16] <merbzt> the address space looks really strange [15:54:23] <kshishkov> no KDE on my x86 box [15:54:34] <kshishkov> (not on any other box too) [15:54:36] <BBB> I may be looking wrongly here [15:54:42] <BBB> but this dll handles WMVP [15:54:47] <astrange> i'm not sure -sameq does what he wants [15:54:50] <BBB> I don't see too many references to WVP2 in the .text segment [15:54:51] <BBB> hmm... [15:54:54] <BBB> what's WMVP? [15:55:06] <kshishkov> first version of WVP2 [15:55:13] <BBB> and what's WMVA? [15:55:37] <kshishkov> VC-1 [15:56:01] <kshishkov> bitstream format is the same at least [15:57:44] <kshishkov> not to mention the only change needed for FFmpeg to support it was adding fourcc to libavformat/riff.c [15:58:16] <BBB> hmm... [15:58:22] * BBB ditches dll and goes look for correct one [15:58:51] <kshishkov> what're you looking for? [15:58:56] <BBB> the WVP2 DLL [15:59:01] <BBB> I don't think I had the correct one [15:59:08] <kshishkov> but it is [15:59:24] <BBB> it isn't, the fourccs handled by it in the list were WMVA, WMV1/2/3 and WMVP [16:00:04] <BBB> grep WVP2 gives a match, but a quick look for the text in it reveals nothing [16:00:19] <kshishkov> in what text? [16:00:32] <BBB> whole binary? [16:00:40] <BBB> "search for text" in ida [16:00:48] <kshishkov> it's numeric constant [16:00:57] <kshishkov> try in hex view first [16:01:15] <BBB> all others are strings [16:01:19] <BBB> zero-terminated, etc. [16:01:26] <BBB> and with actual names [16:01:29] <BBB> aWmv1 [16:01:31] <BBB> aWmv2 [16:01:33] <BBB> etc. [16:01:35] <kshishkov> ignore those [16:02:00] <ramiro> mru: help me out here, does this reply make any sense?: http://sourceforge.net/mailarchive/message.php?msg_name=20100317215845.GA20… [16:02:19] <BBB> oh! [16:02:27] <BBB> i failed to parse one string [16:02:33] <BBB> I can see it in the binary between the others [16:02:35] <BBB> funny [16:03:20] <kshishkov> BBB: guess who disasmed that DLL before you? [16:03:46] <BBB> hence my asking ;) [16:03:51] <BBB> why didn't you complete it? [16:04:13] * kshishkov is verry lazy [16:05:33] <roozhou> Question on AVI muxer ---- nBlockAlign in WAVEFORMATEX should be size of uncompressed pcm data in bytes of one frame for compressed audio codec [16:05:48] <roozhou> ?? [16:05:59] <BBB> no, size of one block of compressed data [16:06:12] <BBB> at least in asf, if you don't have it you can't decode most wma formats [16:06:42] <roozhou> for AAC, what value? [16:07:25] <kshishkov> BBB: please do the following - go to the instruction at address 8c46b32, move cursor to number and press 'r' [16:07:59] <roozhou> ffmpeg writes 4, and it results in A/V async [16:08:15] <BBB> you are scary [16:08:37] <kshishkov> isn't A/V sync a good thing to have? [16:08:55] <merbzt> sync v= async [16:09:22] <jai> roozhou: should be set to max frame size possible [16:09:28] <mru> ramiro: they're idiots, you might as well give up [16:09:36] <roozhou> AVI_Mux_GUI writes 4096 [16:09:50] <mru> ramiro: how are orcc and liborc related? [16:10:03] <jai> well, yeah, if you are muxing from raw aac [16:10:06] <jai> 1024 samples [16:10:15] <roozhou> i am muxing from mp4 [16:10:29] <roozhou> each aac frame has 1024 samples [16:10:44] <kshishkov> BBB: any result? [16:10:54] <BBB> kshishkov: I did it, as I said, you are scary [16:11:11] <BBB> very scary [16:11:23] <kshishkov> why? because it's written backwards? [16:11:31] <jai> roozhou: yeah, are you saying that the it isnt calculated correctly in out muxer? [16:11:34] <jai> *our [16:11:38] <BBB> kshishkov: you are just plain scary :) [16:11:53] <roozhou> jai: right [16:12:11] <jai> roozhou: hmm, weird. never heard this before, let me check [16:12:24] <kshishkov> BBB: ask mru or merbzt - they've seen me in real life. Twice. [16:12:37] <mru> and lived to tell the tale [16:12:46] <roozhou> once i modify nBlockAlign in hex editor to 4096, it plays ok [16:13:42] <roozhou> ffmpeg produces broken aac in avi for years, because of this bug [16:15:04] <jai> roozhou: is there a bugreport on our tracker for this? [16:15:36] <BBB> mru: is he scary? [16:15:41] <BBB> mru: he certainly sounds scary :) [16:15:42] <roozhou> i don't know [16:16:24] <kshishkov> BBB: in any case I probably the scariest Ukrainian you know [16:16:39] <BBB> unlikely, I know another one and he's pretty scary also [16:19:32] <jai> also, the 3guys with the infamous hammer [16:19:50] <roozhou> jai: it seems aac parser does not set blockalign so ff_put_wav_header use the default value enc->channels*bps >> 3 [16:20:24] <jai> peloverde: ^ [16:20:47] <BBB> kshishkov: I'm imagining where I'm randomly rambling about this dll in this channel while at the same time you're probably having it in front of you right now, steering me from this to that point, like me being a strawman [16:21:17] <av500> BBB: you see strings attached to your hands and head? [16:21:25] <BBB> yes [16:21:28] <BBB> and they're moving [16:21:28] <kshishkov> BBB: no, told you - IDA database with it is on SATA HDD which I can't connect. [16:21:44] <BBB> kshishkov: the fact that you remember the address is scarier [16:22:27] <kshishkov> BBB: objdump -d and quick grepping [16:27:38] <jai> roozhou: i dunno why the mp4 demuxer didnt set block_align properly [16:29:47] <jai> roozhou: can you test a patch for me? [16:30:03] <roozhou> jai: of course [16:35:59] <roozhou> jai: where is the patch? [16:37:34] <jai> roozhou: just a sec, i need to pastebin it [16:40:12] <roozhou> i did a modification in riff.c and it is working for me [16:41:00] <jai> roozhou: riff.c? [16:41:04] <jai> why [16:42:12] <roozhou> blkalign = 1; [16:42:13] <roozhou> } else if (enc->block_align != 0) { /* specified by the codec */ [16:42:13] <roozhou> blkalign = enc->block_align; [16:42:13] <roozhou> + } else if (enc->codec_id == CODEC_ID_AAC) { [16:42:13] <roozhou> + blkalign = enc->frame_size*enc->channels*bps >> 3; [16:42:13] <roozhou> } else [16:42:13] <roozhou> blkalign = enc->channels*bps >> 3; [16:42:14] <roozhou> if (enc->codec_id == CODEC_ID_PCM_U8 || [16:53:09] <mru> ramiro: I had a quick look, and I can't see a way to configure orcc as a cross-compiler [18:00:55] <peloverde> I can't believe I find myself agreeing with Joel: "If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics. /We have better technology now./" [18:01:15] <mru> yeah, read that [18:02:08] <elenril> did that flame about git on -cvslog a few days ago go anywhere? [18:03:17] <mru> of course not [18:03:45] <mru> michael insists on "svn cp", diego insists on making up history, we're not going anywhere [18:04:29] <peloverde> I think we will wind up on git soon or later, and I think there will be a less painful transition if we side with sooner [18:04:41] * kshishkov wonders why his SheevaPlug hangs but still responds to pings - faster than other hw on LAN [18:04:41] <peloverde> Git notes allows you to add footnotes to the history [18:05:25] <mru> rewriting history is a bad idea, get over it [18:05:55] <peloverde> I think git-notes is a good compromise [18:06:16] <mru> I've never felt a need for it [18:06:48] * thresh did [18:06:58] <thresh> but still, you can re-read before you push [18:07:00] <astrange> it's somewhat annoying that git log libavcodec/h264_cabac.c doesn't see through the copy [18:07:08] <astrange> seems like you can't adjust rename detection for that [18:07:45] <peloverde> Diego likes to make the wrong contributor argument, suppose person 1 sends a patchset and you misattribute it to person 2 [18:08:06] <thresh> no such problem for git [18:08:12] <thresh> you just git am [18:08:14] <peloverde> however requiring git formatted patches could solve that problem much more easily [18:08:40] <mru> astrange: try git gui blame [18:09:07] <peloverde> thresh, what about changes from a hostile downstream? [18:09:14] <mru> and misattributions are such a HUGE problem??? [18:09:26] <mru> we have my shotgut for that [18:09:44] <DonDiego> i arrive at an interesting moment? [18:09:47] <peloverde> speak of the devil :) [18:09:51] <_av500_> i have one patch to defend with my life! [18:09:59] * DonDiego hears talk of mans' shotgun.. [18:10:35] * DonDiego is on the lookout should the devil sneak around [18:11:13] <DonDiego> anyway, i have noticed some issues with libswscale on powerpc [18:11:29] <mru> go on [18:11:30] <DonDiego> lu_zero, ramiro, siretart`, you around? [18:11:48] <DonDiego> compilation fails with the following combination of configure flags: [18:12:12] <DonDiego> --enable-gpl --enable-swscale --enable-runtime-cpudetect --disable-altivec [18:12:27] <DonDiego> (--enable-gpl is probably not necessary to trigger the failure) [18:12:51] <kshishkov> try compiling it with --disable-swscale [18:12:52] <mru> --enable-swscale is no more [18:13:04] <mru> are you talking about the release branch? [18:13:19] <peloverde> I wish it were un-no-more, svn:externals are annoying [18:13:45] <DonDiego> no, i'm talking about trunk [18:13:45] <mru> svn externals are a work of the devil [18:13:51] <kshishkov> peloverde: when it's fully LGPL we can put it into main repo and screw that history [18:14:07] <peloverde> kshishkov, we've had GPL code in trunk before [18:14:18] <mru> we have gpl code in trunk now [18:14:21] <peloverde> I don't understand why pure LGPL is a prereq for merging [18:14:23] <DonDiego> utils.c, lines 1024 and 1528 [18:14:24] <mru> and ffmpeg doesn't work w/o it [18:14:46] <DonDiego> back to topic please.. [18:14:49] <kshishkov> peloverde: someone likes history [18:14:50] <astrange> you can merge it into svn with history, just turn off cvslog for the 100000 commits [18:14:53] <mru> failure confirmed [18:15:01] <DonDiego> the preprocessor condition reads [18:15:03] <DonDiego> -#if ARCH_PPC && (HAVE_ALTIVEC || CONFIG_RUNTIME_CPUDETECT) [18:15:24] <DonDiego> that won't work if you disable altivec [18:15:32] <kshishkov> astrange: and bad CIA bot too [18:15:35] <kshishkov> *ban [18:16:02] <DonDiego> i think the 0.5 branch is fine [18:16:15] <mru> astrange: have you ever tried following its history all the way back? [18:16:45] <astrange> not aside from having a git checkout of it [18:17:05] <mru> it's been moved around and renamed several times [18:17:26] * kshishkov is proud to shorten yuv2rgb.c history a bit [18:17:58] <mru> history is append-only [18:18:05] <peloverde> pointing to the old history in the commit message should be viable [18:18:39] <mru> just dumping it in and ditching the history will totally break bisecting before that point [18:18:54] <mru> it's broken now too, but let's not make it permanent [18:19:02] <mru> if it is at all fixable [18:19:08] <peloverde> bisecting is already broken [18:19:18] <mru> so fix it, don't break it more [18:19:20] <peloverde> then let's start a new repo and interleave them [18:19:29] <mru> how do you do that? [18:19:44] <peloverde> play back both histories simultaneously [18:19:48] <mru> how? [18:20:25] <peloverde> how would you commit it all on top of what we have in ffmpeg/trunk? [18:20:35] <peloverde> just do that with two instead of one [18:20:48] <mru> that would break bisecting [18:20:52] <mru> even more than it is now [18:21:03] <peloverde> how would that break bisecting? [18:21:22] <mru> a checkout of an old rev/date would give no libswscale at all [18:21:46] <mru> now you can at least do an svn checkout by date [18:21:51] <peloverde> you misunderstand me [18:22:05] <peloverde> A) do a full history checkout of both [18:22:11] <peloverde> B) set up a new repository [18:22:13] <mru> what does that mean? [18:22:24] <peloverde> mru, git svn clone [18:22:56] <peloverde> set up two pointers one to r1 of both swscale and ffmpeg [18:23:08] <mru> pointers? [18:23:22] <peloverde> variables holding revision numbers [18:23:25] <peloverde> D) compare dates, apply the older and advance the pointer [18:24:22] <janneg> the svn commit dates are sane? [18:24:35] <mru> should be [18:25:46] <peloverde> or we could wait until the magical svn fairies bless us with a merge-o-matic... some time after we are all dead [18:27:50] <ramiro> mru: apparently orcc doesn't have to be built as cross-compiler. any build supports all targets. but schroedinger uses the same PKG_CONFIG to get orcc and liborc. it must link to liborc (for mingw32), and run orcc on build machine. [18:28:24] <ramiro> but then he says "This is pretty normal practice for packages that create build tools." (that you should build the package twice and somehow set ORCC even thought it's undocumented) [18:28:30] <mru> ramiro: that's not what I saw [18:28:37] <DonDiego> any suggestions what the correct condition for libswscale is? [18:28:39] <_av500_> mru: like ogg strict interleaving :) [18:28:43] <mru> it is not possible to build it on x86 to target arm [18:28:45] <mru> eg [18:29:37] <ramiro> http://bugs.freedesktop.org/show_bug.cgi?id=27103#c1 he says "There's no target dependency in orcc" [18:29:48] <mru> is a lie [18:29:54] <mru> I looked at the code today [18:30:08] <mru> if you build on x86, all non-x86 targets are disabled [18:30:15] <mru> etc. [18:31:27] <DonDiego> also [18:32:11] <DonDiego> in swscale.c the COMPILE_TEMPLATE_foo tokens are defined to 1, but the COMPILE_foo tokens are just defined [18:33:01] <DonDiego> but we have the following in there: [18:33:09] <DonDiego> #if ARCH_PPC && COMPILE_ALTIVEC [18:33:14] <DonDiego> that's broken.. [18:33:30] <BBB> oh, we're in gsoc [18:33:31] <BBB> yay [18:33:59] <DonDiego> ramiro: you created libswscale/utils.c i think.. [18:34:48] <BBB> I wonder why they sent that to me [18:34:55] <BBB> maybe mike made my email address co-admin? [18:35:33] <kshishkov> BBB: not all of us but still yay [18:36:03] <ramiro> DonDiego: just svn cp'd it. what's the issue? [18:36:14] <peloverde> A binary w32 loader is back on the table? [18:36:17] <DonDiego> ramiro: scroll up :) [18:36:36] <DonDiego> peloverde: the faq says another thing, but michael seems to like the idea [18:36:37] <peloverde> BBB, hurrah! [18:36:47] <BBB> we should not put it in svn [18:36:50] <mru> ugh for win32 loader [18:36:53] <DonDiego> i think he wants ffplay to put mplayer out of business [18:36:56] <BBB> but it'd be useful for us while RE'ing codecs [18:37:01] <mru> ffplay is a toy [18:37:05] <DonDiego> a waste of effort better spent elsewhere imo [18:37:07] <BBB> does anyone use ffplay? [18:37:10] <peloverde> DonDiego, I'd rather have vo_gl [18:37:20] <DonDiego> i use ffplay to test samples, nothing more [18:37:43] <DonDiego> BBB: you can use mplayer while REing codecs... [18:37:57] <BBB> ffmpeg is smaller codebase [18:37:59] <BBB> makes it simpler [18:38:04] * BBB very stubborn [18:38:20] <DonDiego> bbl [18:38:38] <DonDiego> mplayer is not a particularly big codebase [18:38:49] <DonDiego> probably smaller if you take away the embedded libs [18:38:52] <kshishkov> but particularly hacky [18:39:20] <BBB> ohwell [18:39:22] * BBB goes work [18:39:24] <elenril> only some parts [18:39:40] <jai> most parts [18:40:30] <mru> the core parts [18:41:37] <DonDiego> getting better :) [18:42:48] * jai waits for uoti to comment ;) [18:42:53] <jai> oh wait, he isnt here [18:43:23] <mru> he got banned for bad behaviour [18:43:40] <jai> oh [18:44:23] <Compn> ehe win32 loader in ffmpeg [18:44:32] <mru> where's this being discussed? [18:44:41] <astrange> mplayer list [18:44:49] <kshishkov> mru: I gave you link once [18:45:33] <peloverde> mru: [MPlayer-dev-eng] [PATCH] Fix return values of WaitForSingleObject when checking an event [18:45:43] <BBB> astrange: if you want a w32 loader in ffmpeg, shouldn't it be discussed on ffmpeg-devel? [18:47:00] * _av500_ uses ffplay to RE lavc/lavf [18:47:43] <mru> BBB: maybe they fear too much resistance there [18:48:02] <astrange> it's not being discussed yet, michael just suggested it [18:48:31] <mru> shouldn't ffmpeg changes be _suggested_ on ffmpeg-devel? [18:48:41] <BBB> probably [18:48:50] <BBB> anyway, I for one am dead-on against such a loader in ffmpeg [18:49:01] * mru too [18:49:05] <ramiro> DonDiego: open a bug on the bug tracker and I'll take a look later [18:49:53] <Compn> BBB : you could change ffmpeg from a set of decoder and encoders into a unified wrapper for all codecs, ever made! [18:49:54] <Compn> ;p [18:50:05] <mru> sounds like mplayer [18:52:16] <BBB> if I wanted to develop mplayer, I'd subscribe to a mplayter ML [18:52:23] <BBB> surprise, surprise, I'm not on the list :) [18:53:06] <jai> same here, though i read archives [18:53:19] <peloverde> I wound up subscribing to m-d-e just because ffaac periodically comes up [18:58:58] <jai> kshishkov: btw, apparently i _can_ participate in gsoc this year :) [18:59:29] <kshishkov> good for you [19:03:10] <BBB> Compn: somehow that sounds like gstreamer ;) [19:03:12] <BBB> </late> [19:03:19] <BBB> jai: go do ralf :) [19:03:38] <BBB> kshishkov: I wish you could participate, would be good... you could do vc-interlaced [19:03:41] <thresh> ffmpeg is in GSOC 2010, congrats [19:03:50] <BBB> my wife tried to convince me to participate as student [19:04:04] * kshishkov always though they called it Ralf so because codec devs had the brains of Ralf Wiggum [19:04:06] <BBB> which, if I jump through some hoops, might in fact be possible [19:04:19] <ramiro> mru: it seemed to work fine to call "orcc --target arm" to cross-compile. [19:04:38] <mru> well, *something* is disabled [19:04:43] <kshishkov> BBB: do it, it has nothing to do with university anyway ;) [19:05:01] <mru> http://code.entropywave.com/git?p=orc.git;a=blob;f=orc/Makefile.am;h=3799dd… [19:05:03] <BBB> it involves doing stuff [19:05:23] <ramiro> mru: I think it's the code that gets information from cpuid and such. [19:06:29] <kshishkov> BBB: it's nothing hard [19:07:23] <kshishkov> BBB: learn from my example - I did RV4 decoder (REing and implementing) during exams and finishing thesis for bachelor degree [19:08:14] <BBB> I still don't know which function is the main decoding function :) [19:08:32] <kshishkov> where? [19:08:40] <BBB> wvp2 [19:08:45] <kshishkov> neither do I [19:08:48] <BBB> I'm sort of browsing through it, little by little [19:08:57] <BBB> I hate that com-style stuff [19:09:08] <kshishkov> I just found functions used for decoding [19:09:15] <kshishkov> that's enough even without main [19:09:16] <BBB> I'm now going through it using the mplayer/gstreamer win32 loader code, so at least I know the offset of vfuncs in structs [19:09:40] <kshishkov> eww [19:09:59] <BBB> don't ask ;) [19:10:04] <BBB> I told you I have no idea what I'm doing [19:10:06] <BBB> just trying random things [19:10:40] <ramiro> bbl [19:10:54] <kshishkov> you know, those offsets are stored in data segment (I think), you just need to find correct array of function pointers ;) [19:10:56] <bcoudurier> hi guys [19:11:24] <BBB> I noticed [19:11:29] <BBB> I already figured out a whole bunch of 'em [19:11:32] <BBB> just not the main one yet [19:11:57] <jai> BBB: which codec is this? [19:12:08] <Compn> wvp2 [19:12:18] <Compn> aka wmv3 slideshow + text [19:12:20] <kshishkov> BBB: you can try my way [19:14:23] * kierank would also like to hear about the "kshishkov way" [19:14:53] <kshishkov> it won't work for you since you don't know much about your codec [19:15:02] <kshishkov> but for WVP2 it's easy [19:15:19] <kshishkov> easier at least [19:16:15] <kshishkov> I know how to find extradata parsing function, from it one can trace up more decoding functions [19:16:36] <kshishkov> not mentioning that other functions using get_bits() will belong to decoding ones [19:18:11] <kierank> I started from startcode parsing and worked my way up until I found the gui calling the api [19:19:17] <kierank> though i still haven't figured out why startcodes are parsed in some functions when they don't need to be [19:21:38] <kshishkov> yes, unless it's simple interface like VfW it may be better to pick some function in the middle or end of calling chain and unravel it [19:23:17] <BBB> kshishkov: so how do you do that? [19:23:28] <BBB> load in debugger and put a watchpoint on extradat? [19:23:31] <kshishkov> no [19:23:42] <kshishkov> I just happen to know how it works [19:23:43] <BBB> don't forget I'm still learning [19:23:51] <BBB> wmavoice was easy b/c it had symbols [19:23:57] <BBB> this is the second time I touch something w/o symbols [19:24:08] <BBB> the first one was when I RE'ed SVQ3/QDM2 RTP payload formats [19:24:21] <kshishkov> so if some code calls function with argument 3 then with argument 5 then it must be get_bits() in wmv2 or wmv3 extradata parsing [19:25:55] <BBB> ? [19:27:12] <kshishkov> just a sec... [19:32:22] <kshishkov> 8c5de0a seems to be a good candidate for either wmv2 or wmv3/wvp2 extradata parsing [19:33:03] <kshishkov> also remember that condition I've told you to convert earlier? It also should belong to codec initialization [19:35:01] <mru> ok, here's one for the svn historians [19:35:20] <mru> look at r151 in ffmpeg and r2159 in libswscale [19:38:28] <DonDiego> mru: what about it? [19:38:39] <mru> same files in different places [19:39:19] <mru> the following commits are also duplicated in both places [19:39:21] <BBB> kshishkov: so how do you know? [19:40:35] <DonDiego> that's because postproc started out in mplayer [19:40:48] <DonDiego> i think arpi just moved the cvs directory [19:40:51] <DonDiego> physically [19:41:01] <mru> ah, good old cvs [19:41:23] <DonDiego> the world is so much better now.. [19:41:31] <mru> now we only have svn to kill [19:41:46] <j-b> and bzr [19:42:02] <mru> you can't kill something if it ain't alive [19:42:20] <kshishkov> BBB: told you, objdump -d and grepping [19:42:43] <DonDiego> i use bzr at work now [19:42:49] <DonDiego> (along with svn) [19:43:01] <kshishkov> mru: what about zombies? [19:43:10] <mru> DonDiego: masochistic tendencies? [19:43:12] <DonDiego> it's such an immense step up from tla, which was used previously.. [19:43:23] <mru> or machosistic? [19:43:32] <mru> -h [19:44:00] <kshishkov> mru: Germans even wrote _network_ version of M$ Source Safe which is damn inconvenient to use even by single developer [19:44:30] <mru> broadcom uses sourcesafe [19:44:35] <mru> it shows in the result [19:44:48] <DonDiego> bzr is ok, it gets the job done [19:45:00] * BBB hugs kshishkov [19:45:05] <BBB> kshishkov: unfortunately, that's the wmv3 code [19:45:12] <mru> it's just a bit clunky and doesn't scale very well [19:45:14] <kshishkov> mru: looks like my SheevaPlug is pining to the fjords. Any advise? [19:45:18] <DonDiego> the two drawbacks i noticed are not being able to edit log messages and lack of copy support (with history) [19:45:22] <mru> kshishkov: reboot? [19:45:28] <BBB> I already saw the caller function earlier, it handles seprarate call paths for wmv1, wmv and wmv3/a/r [19:45:32] <BBB> but it doesn't handle wvp2 [19:45:36] <BBB> which appears to be done elsewhere [19:45:42] <kshishkov> mru: done cold reboot, does not help [19:45:42] <mru> DonDiego: you do have strange requirements [19:45:49] <mru> kshishkov: what does it do? [19:45:52] <elenril> hey, metadata writing for flac still isn't applied? [19:45:55] <mru> anything on serial console? [19:45:56] <DonDiego> have you ever used tla_ [19:45:59] <DonDiego> ? [19:45:59] <elenril> J_Darnley: you should complain more ;) [19:46:02] <mru> goodness no [19:46:02] <kshishkov> BBB: wvp2 is handled as wmv3, believe me [19:46:11] <BBB> ok [19:46:19] <BBB> but the switch/case in the caller doesn't handle wvp2 [19:46:32] <kshishkov> mru: no, forums suggest it may be power supply melted [19:46:33] <mru> http://changelog.complete.org/archives/698-if-version-control-systems-were-… [19:46:34] <BBB> so it might be that the *extra* code that handles wvp2, specifically, is elsewhere [19:46:42] <mru> kshishkov: the PSU in mine died a while back [19:46:45] <mru> busted cap [19:46:47] <mru> easy fix [19:46:57] <kshishkov> now only to find tools [19:47:44] <kshishkov> mru: I remember similar text about OSes [19:48:03] <mru> about tla: you arrive as your destination terminal, you see it too is full of philosophers, most of them dining. [19:48:25] <kshishkov> BBB: one of those conditions comparing FOURCCs used "if codec is WVP2 set some flag and go by WMV3 path" [19:48:40] <BBB> that's true [19:48:48] <BBB> it did it really weirdly also [19:49:00] <kshishkov> is that an allusion to fmaous resource allocation/deadlock problem? [19:49:16] <BBB> (fourcc==WVP2)-1&0xE000000+ fourcc(WMV3) [19:49:17] <mru> I would presume so [19:49:17] <BBB> or so [19:49:22] <kshishkov> yes [19:49:35] <kshishkov> it just does ?'WMV3':'WMVA' [19:49:37] <mru> and of bzr: Main competitor: BeOS Airlines [19:50:51] <kshishkov> better than Hurd Airlines [19:51:15] <mru> what's that? a gnu with painted-on wings? [19:51:38] <kshishkov> yes [19:52:03] <kshishkov> flies as well as accountants from the top floor [19:53:23] <BBB> kshishkov: hm, is that the same function I'm talking about? [19:53:25] * BBB checks again [19:53:38] <BBB> maybe it's because it does a direct fourcc calc that I misinterpreted the 0xE0000000000000 [19:53:45] <kshishkov> yes, the same code you copypasted [19:53:48] <BBB> ok [19:53:53] <BBB> I misinterpreted that then [19:54:06] <BBB> so then wvp2 ====== wmv3 in all practical senses [19:54:09] <BBB> except for that one flag [19:54:25] <kshishkov> yes, and some flags set to zero in wmv3 [19:54:31] <BBB> 8c4cec6 [19:54:37] <BBB> hm, no [19:54:40] <kshishkov> i.e. end of sequence header parsing differs for them [19:55:22] <BBB> shit I can't find it anymore [19:57:14] <BBB> 8c47f60 [19:59:10] <BBB> so WVP2 -> WMVa, and WMVP -> WMV3? [20:00:27] <kshishkov> probably both are WMV3 [20:00:55] <kshishkov> if extradata and frame start with NAL code (00 00 01) then it's WMVA [20:01:16] <BBB> the code triggers for WMVP/WVP2 [20:01:22] <BBB> test fourcc, WVP2 [20:01:26] <BBB> setnz ecx [20:01:29] <BBB> dec ecx [20:01:32] <BBB> and ecx, 0xE [20:01:35] <BBB> add ecx, WMV3 [20:01:54] <BBB> so WVP2->0->-1->E->WMVA [20:01:58] <BBB> WMVP->WMV3 [20:02:17] <BBB> interesting code btw [20:02:22] <BBB> is gcc that good?> [20:02:58] <kshishkov> unlikely [20:04:16] <kshishkov> for all practical reasons you can treat them as WMV3 for now [20:04:26] <kshishkov> I've looked into actual WMVP and WVP2 file [20:04:57] <BBB> ok [20:08:36] <Compn> wouldnt the easier way be to just encode the same video in wvp2 and wmv3 and compare them? :P [20:08:49] <kshishkov> go on [20:38:25] <mru> http://daringfireball.net/2010/03/mozilla_video_mobile [20:42:17] <BBB> nice post [20:59:44] <DonDiego> hey, why hasn't anybody informed me about the html 5 situation? [20:59:46] <DonDiego> :) [21:00:07] <mru> DonDiego: you can read news/blogs just like the rest of us, no? [21:00:29] <DonDiego> no, i'm supposed to do other things and sometimes i actually do ;) [21:06:24] <BBB> hml5 is simple: as predicted, theora lost [21:06:32] <BBB> I don't see any news there [21:06:59] * mru hopes this will be another nail in mozilla's coffin [21:07:06] <BBB> mozilla is cool [21:07:15] <BBB> those involved in video should be fired [21:07:16] <mru> errr, no [21:07:22] <mru> firefox sucks [21:07:43] <mru> I only use it because the alternatives so far have sucked more [21:07:48] <mru> and because of inertia [21:07:54] <BBB> I think you're too much a hardliner, sorry, but within the mozilla foundation, I know for a fact there are many different opinion on how video should be handled [21:07:54] <bcoudurier> what's the news ? [21:08:01] <mru> there is no news [21:08:18] <mru> of course there are differing opinions inside mozilla [21:08:21] <bcoudurier> what is diego talking about ? [21:08:24] <mru> it's large enough an organisation for that [21:08:26] <BBB> it's unfortunate that those with bad, poor and uninformed opinions, the freetards as you'd call them, are most vocal [21:08:35] <BBB> chris blizzard, for example [21:08:36] <mru> bcoudurier: ms announced that ie9 will support h264 [21:08:40] <BBB> he's an absolute idiot [21:08:45] <bcoudurier> haha [21:08:47] <BBB> many others are quite smart [21:09:00] <bcoudurier> I don't use firefox anymore [21:09:08] <mru> what do you use? [21:09:09] <bcoudurier> chrome works a lot better IMHO [21:09:22] <mru> does it have an addon like stylish for firefox? [21:09:25] <bcoudurier> and on osx I use safari because I'm lazy [21:09:32] <bcoudurier> stylish ? [21:09:43] <mru> custom per-site/page css overrides [21:09:46] <mru> I use it all the time [21:09:52] <bcoudurier> oh I don't use that [21:09:58] <bcoudurier> I don't use any plugin [21:10:15] <mru> it lets me adjust the look of sites I visit often [21:10:22] <mru> make them more readable [21:10:36] <bcoudurier> my eyes works nicely [21:10:42] <mru> mine too [21:10:46] <mru> but some fonts are just too ugly [21:10:49] <mru> and some colours [21:10:52] <mru> and some layouts [21:11:46] <mru> like who the hell sets a long text in a sans-serif font? [21:12:29] <DonDiego> bcoudurier: you browse without adblock? [21:12:34] <bcoudurier> I guess it's only a matter of bad taste [21:12:34] <DonDiego> wow, go figure.. [21:12:43] <bcoudurier> yes I see adds [21:12:47] <bcoudurier> ads [21:12:49] <DonDiego> geez [21:12:56] * DonDiego shrieks [21:12:58] * mru thanks bcoudurier for sponsoring the web for the rest of us [21:13:06] <bcoudurier> no pb [21:13:15] <DonDiego> doesn't you brain get fried after a while [21:13:27] <bcoudurier> well, I like the news websites [21:13:33] <DonDiego> sometimes i approach slot machines [21:13:34] <bcoudurier> I don't buy the papers [21:13:48] <bcoudurier> that's the only way I can give them money ;) [21:14:00] <DonDiego> only to notice that they are some other person's computer showing the web in all it's ad-enabled furor... [21:14:26] <bcoudurier> I wonder where you guys are surfing [21:14:31] <bcoudurier> you do too much pron [21:14:42] <DonDiego> generic news sites [21:14:58] <DonDiego> leo.org, anything really... [21:16:22] <DonDiego> i do wonder if mozilla has a fallback plan.. [21:16:41] <mru> stick fingers in ears and mumble "patents, patents, patents" [21:16:54] <DonDiego> mru: i need to send a mail to alp toker about his firefox with webkit backend... [21:17:14] <iive> DonDiego: i think mozilla fallback plan is to use gstreamer. [21:17:58] <iive> bcoudurier: i'm yet to see news site that deserves my 2 cents. [21:18:18] <BBB> I think they use gstreamer in their mobile firefox version, no? [21:18:30] <DonDiego> in any case, i'm looking soooo forward to the demise of flash... [21:18:31] <ramiro> how many distro packagers do we have around here? siretart`, lu_zero, Rathann, ...? [21:18:38] <BBB> integrating that code into main mozilla has been on hold for ... 2 years or so? [21:19:12] <astrange> i could take over the fink packaging for ffmpeg and co, but i haven't done it just yet [21:19:19] <ramiro> regarding http://sourceforge.net/mailarchive/message.php?msg_name=20100317215845.GA20… and his followup http://ffmpeg.pastebin.com/Cbe6hHXt . It would be nice if distro packagers could each file a bug report about this. [21:19:45] <BBB> dondiego: do you need more help with the invoicing? [21:20:21] <DonDiego> i'm at my parent's house right now [21:20:26] <BBB> oh, n/m then [21:20:27] <DonDiego> my dad hasn [21:20:32] <DonDiego> 't been well [21:20:38] <Rathann> ramiro: what's the issue? [21:20:49] <DonDiego> i'm going home and will look at it again then [21:21:05] <BBB> ok [21:21:13] <DonDiego> either i find a template that produces better results in >1h or i send it off as-is [21:21:17] <ramiro> Rathann: http://bugs.freedesktop.org/show_bug.cgi?id=27103 [21:21:21] <DonDiego> they will likely have comments anyway [21:21:47] <DonDiego> ok, i'm out now [21:21:48] <DonDiego> bbl [21:22:33] <ramiro> Rathann: and libschroedinger depends on liborc. it is not possible to cross compile libschroedinger with a simple configure. you *must* (after some time asking why) hardcode a variable inside configure so that it does not use pkg-config to fetch a wrong variable. [21:23:10] <ramiro> more specifically you must set ORCC to the native orcc [21:23:23] <peloverde> Solution: Ignore their silly fringe format if they are unwilling to be reasonable about it [21:23:37] <ramiro> he insists that's the correct way to do things, and that there are no bugs or misdesigns. [21:23:56] <mru> ignore and move along [21:24:07] <mru> who needs that stuff anyway? [21:24:27] <ramiro> peloverde: I thought about that, really... but then someone came up with a patch fixing another windows issue with libschroedinger and people are asking for it. [21:24:46] <Rathann> or whip up a patch that doesn't change their defaults but allows you to do what you want [21:24:52] <Rathann> and post it [21:24:52] <ramiro> (people who use the builds at ffmpeg.arrozcru.org ) [21:24:58] <Rathann> see if they accept [21:25:20] <ramiro> Rathann: I could, but that should be their work after I reported the bug =) [21:25:39] <Rathann> in an ideal world [21:25:46] <thresh> you can compile liboil in x-compile [21:25:54] <thresh> at least VLC has patches in its tree to do that [21:25:57] <ramiro> thresh: the new fad is liborc, not liboil =) [21:26:01] <thresh> okay [21:26:17] <ramiro> btw they're all written by the same guy. [21:26:38] <ramiro> who also insists that we shouldn't want to compile his code statically. [21:27:08] <thresh> weird [21:27:33] <thresh> last time i checked Schleef was sane [21:28:04] <mru> doesn't look like it to me [21:28:33] <thresh> things couldve changed since Sep [21:29:04] <thresh> some people get crazier in autumn and spring [21:30:06] <bcoudurier> flowers ? [21:30:35] <peloverde> Long term exposure to ogg is known to cause brain damage [21:31:19] <BBB> I thought dave was pretty normal [21:31:39] <BBB> although he openly admits ffmpeg's hand-optimized code is better than the oil/orc/... autogenerated code [21:32:51] <thresh> 'although' ? [21:33:59] <ohsix> point is behind the chinese wall things can get better [21:34:36] <BBB> http://www.schleef.org/blog/2009/09/19/cog-in-gst-plugins-bad/ [21:35:12] <BBB> hm, in fact that's ffmpeg's C against his automatically crafted asm [21:35:23] <BBB> oddly, ffmpeg's C is faster for the most interesting codepaths than his asm [21:35:26] * BBB wonders [21:37:08] <thresh> wait, this blog post says cog is faster than ffmpeg [21:37:28] <astrange> ffmpegcolorspace doesn't use ffmpeg anymore [21:37:36] <astrange> since imgconvert was removed [21:37:40] <BBB> "a few cases (which, not coincidentally, are the most heavily used cases) ffmpegcolorspace is slightly faster than cogcolorspace." [21:37:42] <mru> it may well be for combinations we don't have direct paths for [21:37:46] <thresh> ah, most heavily used use cases are faster in ffmpeg [21:37:47] <thresh> right [21:37:56] <BBB> mru: that's indeed the case [21:38:03] <BBB> the typical ones is where ffmpeg's C is faster [21:38:12] <mru> we end up going over an intermediate format [21:38:21] <BBB> I think I copied ffmpeg's imgconvert.c /- 6 years ago [21:38:27] <BBB> ffmpegcolorspace still uses that version [21:38:29] <BBB> it's C-only [21:38:33] <BBB> it was never updated [21:38:53] * BBB feels bad for all the code-forking he did back then [21:38:59] <BBB> ahwell, anyway [21:39:30] * mru orders BBB to locate and destroy every fork he made during his time of sin [21:39:35] <BBB> I think for a while there were two ffmpegcolorspace elements [21:39:39] <BBB> one inside gst-ffmpeg [21:39:42] <BBB> which was not to be used [21:39:47] <BBB> and one inside gst-plugins-something [21:39:50] <KotH> janneg: i just rebooted fogir [21:39:52] <BBB> which we were supposed to use [21:39:59] <BBB> because we couldn't depend on ffmpeg [21:40:04] <KotH> janneg: because the oom killer fucked up the machine somewhen this afternoon [21:40:08] <BBB> of course, the one in gst-ffmpeg was using asm and the other one was not [21:42:05] <peloverde> Does modern gst-ffmpeg use sws? [21:43:03] <twnqx> janneg: i suppose the server is gone more permanently... [21:43:16] <twnqx> can i give you the image by another means? :S [21:43:54] <BBB> peloverde: I suppose they use "cogcolorspace" now? [21:44:05] <BBB> not sure [21:44:07] * BBB not involved [21:44:58] <astrange> that reminds me, sws should maybe print a warning if it was built without asm [21:45:32] <janneg> KotH: oh, I noticed that my ssh connection was stuck but was to busy to reconnect [21:45:44] <janneg> twnqx: I giot the tarballs [21:45:48] <twnqx> oh ok [21:45:50] <twnqx> lucky you. [21:46:02] <twnqx> while adding the two missing disks to the raid 6 [21:46:21] <twnqx> i had 92 read errors on one of the active drives [21:46:27] <janneg> it was only a matter of a couple of minutes [21:46:32] <peloverde> gstffmpegscale.c: #include <libswscale/swscale.h> :) [21:46:38] <twnqx> which now means 3 missing with only two survivable. [21:46:57] <twnqx> and a server that doesn't give me an ssh shell. [21:47:03] <KotH> janneg: yeah [21:47:28] <janneg> KotH: last frame finished at 13:47 [21:47:35] <KotH> janneg: i just went trough my emails and saw oom messages from fogir in my inbox and wanted to check... and wasnt able to log in anymore..not even from console [21:47:51] <twnqx> janneg: however, the rendering box is still alive, so i'll finish the block [21:48:42] <janneg> KotH: I'll start a different job [21:50:06] <KotH> twnqx: bad luck with your machines? ^^' [21:50:17] <twnqx> one of them [21:50:29] <twnqx> i'll just throw that piece of junk away [21:50:38] <janneg> was there something else running on fogir? the OOM killer was always precise and killed only blender [21:51:40] <KotH> no, i've nothing running on it at all [21:51:54] <KotH> it's just rendering [21:52:00] * twnqx throws his dual opteron minus ram and harddisks at koth [21:52:35] <KotH> hmm... if it would be with ram, i'd take it [21:53:18] <twnqx> nah [21:53:28] <twnqx> the 16G will complement the 16 in the quad [21:53:46] <KotH> bäh! [21:54:04] <twnqx> yeah, 1G/core is not quite enough [21:54:11] <KotH> lol [21:54:43] <mru> some of my machines have 4G per core [21:54:48] <mru> (single-core) [21:57:06] <KotH> janneg: according to the logs, the oom killed bender... three times ^^' [22:02:52] <janneg> with a couple of minutes between? I restarted the job after frame 97 [22:06:22] <KotH> there were quite a few minutes in between [22:09:49] <janneg> so it doesn't like to get OOM-killed repeatedly [23:30:49] <ramiro> why is it that autogen scripts insist on calling configure? it's annoying... [23:31:30] <mru> cargo cult at its best [23:31:43] <mru> orc? [23:31:53] * mru noticed it had one of those [23:33:15] <ramiro> how did you guess? =) [23:34:59] <ramiro> oh, that's very safe. allocate SIZE bytes to write code to be executed. SIZE is hardcoded to 65536. I wonder if it's ever checked before actual writing... [23:35:24] <mru> and even if, how is an overflow handled? [23:55:55] <ohsix> ramiro: releases include generated files, from source control you generate those same files with your distro bits first, you can pass parameters to autogen [23:56:41] <ramiro> ohsix: sure, but I don't *want* to pass parameters to autogen =) [23:56:56] <ohsix> but you want to generate configure :> [23:59:30] <ramiro> yep... and only that.

1 0

IRC log for 2010-03-17
by irc＠mansr.com 18 Mar '10

18 Mar '10

[00:06:40] <bcoudurier> Yuvi, is it easy to extract vorbis frame duration in the demuxer ? [00:17:24] <mru> it's impossible [00:17:33] <mru> without half a vorbis decoder [00:25:29] <Yuvi> bcoudurier: easy, no [00:25:34] <Yuvi> possible, yes [00:25:35] <Yuvi> http://github.com/kfish/liboggz/blob/master/src/liboggz/oggz_auto.c#L648 [00:31:23] * Compn still chuckles at mike being ffmpeg and theora and flash dev [00:32:20] <mru> some irony [00:32:20] <Compn> small multimedia world [00:33:20] <mru> that too [01:43:48] <Dark_Shikari> mru: how fast is clz on armv6? [01:44:25] <mru> one cycle [01:44:39] <Dark_Shikari> 09:43 < derf> The funny bit, is the de Bruijn approach is _faster_ than clz on ARMv6. [01:44:39] <mru> well, on arm11 [01:44:47] <mru> oh, that idiot again [01:45:09] <mru> ask him which armv6 [01:45:38] <mru> https://trac.xiph.org/browser/branches/theora-thusnelda/lib/enc/mathops.c?r… [01:45:42] <mru> that claims arm11 even [01:45:51] <mru> and it's one cycle there [01:46:05] <mru> I don't know of any other armv6 implementations [01:46:49] <Dark_Shikari> gmaxwell proposes it might have been gcc sucking with __builtin_clz [01:46:58] <Dark_Shikari> 09:46 < gmaxwell> The code generated by GCC for CLZ on ia64 looks stupid, and ICC (at least the last version I tried) was actually producing incorrect code. [01:47:14] <mru> didn't I do a blog post on that? [01:47:19] <Dark_Shikari> yup. linked it [01:47:38] <mru> iirc gcc did the right thing on arm [01:47:50] <Dark_Shikari> They might have checked a while ago though. [01:47:57] <Dark_Shikari> I would be entirely unsurprised if it didn't used to do the right thing. [01:48:22] <ohsix> it (builtin) collapses into an invocation of clz if the arch is set, isn't it? [01:48:25] <mru> some version was obviously the first to implement it [01:48:34] <Dark_Shikari> ohsix: and if the phase of the moon is right [01:48:47] <mru> ohsix: only if the operation is defined for that architecture/cpu [01:49:01] <ohsix> well i mean, the builtin isn't actually emitted, it depends on the thing [01:49:04] <mru> if not, it emits a call to __clzsi3 [01:49:19] <mru> or whatever that function is called [01:49:32] <mru> __clzsi2 it is [01:49:41] <mru> never understood that naming convention [01:49:50] <mru> si is "single int" [01:49:53] <Dark_Shikari> scalar int? [01:49:54] <mru> no idea about the 2 [01:50:08] <mru> qi = quarter int (aka byte) [01:50:11] <mru> hi = half int [01:50:21] <mru> di = double int (64-bit) [01:50:59] <ohsix> i think the numbers are just for versions; they keep old versions in libgcc or whatever and supersede them when the abi changes [01:51:14] <ohsix> divsi is up to 3 already [01:51:20] <mru> almost everything is 3 [01:51:52] <mru> internally gcc has things like addsi3, subsi3 etc [01:52:58] <mru> I think the figure denotes the number of operands to the pseudo-instruction [01:53:06] <mru> seems to match [01:53:33] <ohsix> hm yea it does, i had only been looking at *3 stuff so i didn't notice [01:54:17] <ohsix> those files are hard to get around :< [01:54:57] <ohsix> arm esp has some arch files that live in there with their own trampolines and multiple versions/symbols [01:55:14] <mru> the arm files are very complicated [01:55:32] <mru> in part that's due to things like most instructions being conditional [01:55:46] <ohsix> i get them conceptually, but i wouldn't want to internalize it all to make modifications, otherwise you'd fuck it all up [01:55:57] <mru> gcc rtl doesn't seem to have a good way of expressing that [01:56:23] <mru> those files are _very_ fragile [01:56:48] <mru> the slightest change can have bizarre consequences you'd never expect [02:03:09] <mru> Dark_Shikari: any more jokes from the clown? [02:10:35] <mru> Dark_Shikari: gcc 3.2.3 had clz on arm [02:11:48] <mru> that was released in april 2003 [02:18:15] <bcoudurier> bye guys [02:21:00] <Compn> It could be replaced with AVERROR_PATCHWELCOME, though. [02:21:04] <Compn> hehe [02:21:30] <mru> ? [02:22:22] <mfg> Are the recent changes to run a test against fate documented? Can I use that to do a full regression on another change I want to make? [02:22:44] <mru> yes [02:22:53] <mru> you need to download the fate samples first [02:23:05] <mru> http://fate.multimedia.cx/running.html [02:23:26] <mru> then configure --samples=/path/to/samples [02:23:49] <mfg> nice -- ty [02:30:20] <Dark_Shikari> mru: he says ARM1136EJ-S [02:30:29] <Dark_Shikari> and he says it was in fact using the clz instruction [02:32:42] <mru> he's either totally incompetent or a liar [02:32:47] <mru> or possibly both [02:33:11] <Dark_Shikari> do you have one of those? [02:33:18] <mru> yes [02:33:27] <Dark_Shikari> and you've tested, I assume? [02:33:48] <mru> I can't access a cycle counter directly [02:33:59] <mru> and I don't remember if I ever tested that instruction [02:34:04] <mru> the ARM manuals are accurate [02:37:16] <mru> I measured it now on A8 [02:37:17] <mru> one cycle [02:38:25] <mru> one cycle latency [02:38:51] <mru> the A8 can issue two of them per cycle too [02:48:11] <mru> Dark_Shikari: did he say how he measured the time? [02:48:49] <Dark_Shikari> no [02:48:56] <Dark_Shikari> I don't really care [02:49:10] * mru likes a good laugh [03:00:06] <CIA-92> ffmpeg: michael * r22572 /trunk/libavcodec/error_resilience.c: Use H264s MC instead of mpeg4-asp qpel for h264 error resilience. [03:00:44] <Dark_Shikari> oh, so that's why there was that annoying accumulated error. [03:44:11] <CIA-92> ffmpeg: koorogi * r22573 /trunk/libavfilter/ (vf_aspect.c Makefile allfilters.c): Add video filter to manipulate aspect ratio [04:25:34] <CIA-92> ffmpeg: ramiro * r22574 /trunk/libavdevice/vfwcap.c: [04:25:34] <CIA-92> ffmpeg: Do not store a copy of AVFormatContext *s in vfw_ctx. [04:25:34] <CIA-92> ffmpeg: Save *s directly in SetWindowLongPtr instead. [04:36:55] <CIA-92> ffmpeg: ramiro * r22575 /trunk/libavdevice/vfwcap.c: vfwcap: Free remaining packets on vfw_read_close(). [04:38:29] <CIA-92> ffmpeg: koorogi * r22576 /trunk/libavfilter/vf_format.c: Cosmetics: rearrange functions to simplify ifdeffery [04:38:31] <CIA-92> ffmpeg: koorogi * r22577 /trunk/libavfilter/vf_format.c: [04:38:31] <CIA-92> ffmpeg: Allow format and noformat filters to be more completely disabled when the [04:38:31] <CIA-92> ffmpeg: other is enabled. [04:38:31] <CIA-92> ffmpeg: koorogi * r22578 /trunk/libavfilter/allfilters.c: Cosmetics: vertical align [06:45:42] <ohsix> http://www.knjn.com/shop.html?pg=img&src=5140 [06:56:53] <pJok> god morgen, kshishkov :) [06:57:05] <kshishkov> goda morgnar ;) [06:58:19] <thresh> ÑÐŒÑÑÑÐŸ [06:58:56] <pJok> utsikt över malmö central [06:59:34] <kshishkov> thresh: ÐµÐ·Ð¶Ð°Ð¹ Ð² ÐÐžÑÐµÑ ;) [07:00:11] <kshishkov> saw MalmÃ¶ C a couple of times [07:00:48] <pJok> right now it just looks like a big construction site [07:00:58] <kshishkov> Citytunnel [07:01:03] <pJok> japp [07:01:15] <pJok> i look forward to that [07:01:26] <thresh> kshishkov: yeah, to get even worser weather [07:01:27] <pJok> cuts 7 minutes off my trainride to copenhagen [07:01:29] * kshishkov too for some unknown reason [07:01:45] <kshishkov> thresh: I've heard it's consistently bad though [07:02:14] <thresh> yeah, thanks a lot for the support ;) [07:02:18] <kshishkov> pJok: for another unknown reason I like reading http://www.banverket.se [07:03:37] <pJok> so do i [07:03:55] <pJok> but thats mostly because i look forward to hallandsås tunnellen [07:04:24] <pJok> which hopefully gives me trains that run at night as well [07:06:30] <pJok> though that would just be wishful thinking [07:07:00] <kshishkov> heh, here the only major project I heard of is ralway bridge across Dnieper in Kiev [07:07:46] <kshishkov> it could have been built already (and cheaper) if they used European workers and not stole 99.9% of money [07:08:51] <kshishkov> I'm not sure ordinanry man can learn about any projects here [07:09:01] <pJok> two-track railway from göteborg to lund, hallandsås tunnel, north/south tunnel for helsingborg c... exciting stuff [07:09:15] <thresh> kshishkov: the sole purpose of our countries is to steal money [07:09:28] <kshishkov> thresh: yours has oil [07:10:42] <thresh> kshishkov: yeah, like *i* own a oil-rig or something :) [07:11:21] <kshishkov> thresh: there's a word for you in Eglish - Muzhik [07:12:30] <kshishkov> i.e. ordinary citizen of Russia who has only one right - to vote for Yedinaya Rossiya and its leader [07:50:25] <CIA-92> ffmpeg: kostya * r22579 /trunk/libavcodec/indeo5.c: document two variables in Indeo5 decoding context [07:54:04] <CIA-92> ffmpeg: kostya * r22580 /trunk/libavcodec/indeo5.c: [07:54:04] <CIA-92> ffmpeg: Correct reference buffer switching in Indeo 5 decoder. [07:54:04] <CIA-92> ffmpeg: Patch by Maxim ($indeo5decauthor) [08:15:13] <roozhou> hi, anyone knows how to set time_base in stream copy mode? [08:15:45] <kshishkov> the same way as non streamcopy [08:16:00] <kshishkov> isn't it copied from source though? [08:17:01] <roozhou> i tried frame copy H264 from mkv to other container [08:17:24] <roozhou> and it uses different time_base depending on output container [08:21:41] <kshishkov> well, maybe astrange/bcoudurier/Yuvi knows [08:22:00] <roozhou> i am trying to fix stream copy to avi problems [08:23:07] <roozhou> this is the last thing i need to fix [08:23:19] <kshishkov> that's unrealistic ;) [08:24:33] <roozhou> ffmpeg will be the first tool allowing H264 frame copy from mkv/mp4/flv to avi [08:29:10] <superdump> merbzt, janneg : i stopped rendering 05_throwing-04 because it was on all yesterday evening and it did two frames because it was swapping so much [08:29:15] <superdump> not feasible [08:29:33] <superdump> blender really need to code something to avoid excessive ram use [08:29:33] <KotH> not-enough-ram-fail [08:29:43] <superdump> indeed [08:29:49] <superdump> i have 6GB [08:29:51] <superdump> not enough [08:30:06] <kshishkov> superdump: drop Python support? [08:30:08] <KotH> o_0 [08:30:16] <KotH> superdump: wtf? [08:30:26] * KotH wonders how they rendered BBB back then [08:30:36] <superdump> with lots of ram i assume [08:30:41] <superdump> kshishkov: probably not a bad idea [08:31:10] <superdump> it was using upwards of 8GB [08:31:25] <twnqx> ugh. [08:31:29] <kshishkov> KotH: maybe they used smaller resolution [08:31:35] <twnqx> why are you actually rerendering it? [08:31:41] <superdump> i started rendering a different scene that was already underway, though i didn't know [08:31:51] <superdump> that was taking about 5-6 minutes per frame [08:32:02] <kshishkov> twnqx: to pretend later it can be done with array of BeagleBoards in real time [08:32:06] <superdump> twnqx: they're doing it for a 2700x1440 video wall [08:32:18] <twnqx> hm [08:32:39] <twnqx> do you still need nodes? and what's needed to participate? [08:32:55] <kshishkov> more RAM of course! [08:33:03] <twnqx> that's not a prob [08:33:11] <twnqx> i have two pretty idle boxes with 16G each [08:33:12] <superdump> http://jannau.net/bbb_videowall/ [08:33:19] <superdump> they would be handy i expect [08:33:20] <twnqx> and lots of cpu power. [08:33:26] <superdump> lots ==? [08:33:34] <twnqx> one has 7 2ghz opteron cores [08:33:39] <twnqx> the other 16x 2.4 [08:33:39] <superdump> :) [08:33:45] <superdump> niice [08:33:50] <superdump> let em rip [08:34:31] <twnqx> (and don't ask why of all numbers seven...) [08:34:42] <superdump> if you can't get the torrent for firewall reasons, i can upload a tarball of it [08:34:53] <twnqx> torrent's not a prob [08:34:53] <superdump> if you have an ftp [08:34:55] <superdump> ok [08:35:15] <twnqx> disk space is, those are my fileservers & they are in the middle of raid migration :P [08:35:27] <superdump> oh [08:35:44] <twnqx> well [08:35:49] <twnqx> abot 1T free atm [08:35:56] <twnqx> (unassigned LVM space) [08:37:00] <kshishkov> my fileserver has 160GB [08:39:13] <kshishkov> and currently only one box with HDD [08:44:00] <twnqx> superdump: link me the torrent and the setup instructions, please :P [08:45:15] * KotH plugs some wires into twnqx's nose [08:45:19] <KotH> ;-) [08:45:26] <twnqx> ouch :S [08:49:21] <superdump> twnqx: i already did [08:49:26] <superdump> http://jannau.net/bbb_videowall/ [08:49:40] <twnqx> oh. [08:51:38] <twnqx> blender 2.49a will do? [08:52:06] <twnqx> !!! One of the following packages is required to complete your request: [08:52:06] <twnqx> - media-video/ffmpeg-9999-r1 (Change USE: +theora) [08:52:08] <twnqx> noooooooooooooooooo [08:52:13] <twnqx> :S [08:52:46] <KotH> lol [08:53:07] <kshishkov> like an old joke "it needs Theora 1.0 encoder or better that's why I chose x264" [09:13:06] <av500> twnqx: thx for the cpu power! [09:13:52] <twnqx> i'm not ripping videos ATM :P [09:14:20] * av500 can haz login? :) [09:15:07] <twnqx> errr [09:16:19] <av500> for the rips... :) [09:16:22] <av500> (joking) [09:16:30] <twnqx> you like anime? they are all over :P [09:17:21] <twnqx> HM [09:17:30] <twnqx> i need a 50GB rewritable bluray disk :S [09:17:33] <kshishkov> twnqx: you'd better ask that in #mplayerdev [09:18:14] <twnqx> anime ripping & watching are driving x264 and mplayer development, that's a known fact [09:18:43] <kshishkov> no [09:18:52] <kshishkov> for x264 it's Touhou Project [09:18:56] <twnqx> that too. [09:19:26] <Dark_Shikari> well, we optimize for those eroge intros too [09:19:33] <Dark_Shikari> thanks to the japanese providing us with stupidly large amounts of them [09:19:39] <Dark_Shikari> and the entire japanese x264 community testing on NOTHING ELSE [09:19:42] <Dark_Shikari> for some fucked up reason [09:19:52] <kshishkov> literally :) [09:19:57] <Dark_Shikari> ha ha ha [09:20:21] <kshishkov> you should've provided presets for target audiences [09:20:35] <kshishkov> some people may encode _movies_ with x264 after all [09:20:46] <astrange> japanese bug reports for perian tend to be ads for bottled tea [09:20:59] <kshishkov> or something else filmed and not rendered/drawn [09:21:09] <Dark_Shikari> astrange: what [09:21:31] <Dark_Shikari> kshishkov: rendered content is so much fun though [09:21:37] <Dark_Shikari> it completely violates all your assumptions about the nyquist limit [09:21:47] <kshishkov> Dark_Shikari: go tell janneg or av500 that [09:21:57] <Dark_Shikari> well BBB is easy, it has motion blur [09:22:14] <Dark_Shikari> (and ultra low detail/motion, but whatever) [09:22:18] * kshishkov has not thought until recently that "Nyquist" is a typical Swedish name [09:22:29] <Dark_Shikari> nyquist was swedish? [09:23:00] <andoma> yes [09:23:40] <andoma> apparently he's from the same province of sweden as I am! [09:23:49] <kshishkov> indeed [09:23:49] <andoma> VÃ€rmland [09:23:49] <Dark_Shikari> and it's pronounced nyqvist [09:23:50] <Dark_Shikari> not nyquist [09:24:00] <Dark_Shikari> Which sounds MUCH more swedish. [09:24:10] <kshishkov> actually Swedish use "kv" now [09:24:14] <Dark_Shikari> I know [09:24:23] <Dark_Shikari> the point being, the v sounds more swedish [09:24:35] <superdump> wouldn't be pronounced 'n-eye' though [09:24:51] * kshishkov wonders why Hollywood emnployed actors of Swedish origin to fake Russian accent [09:26:00] <kshishkov> superdump: you should have learned how to read Swedish by now [09:26:08] <superdump> i have [09:26:27] <superdump> learning the sounds was one of the first things i did [09:27:00] <superdump> so i was surprised when i met a guy from hong kong recently when he said they learn english for... 10 years or something, but they only learn grammar, never pronunciation [09:27:07] * kshishkov still has troubles pronouncing "sje" properly [09:27:22] <superdump> i don't know what the fuss is about that [09:27:37] <superdump> but maybe i'm not doing it quite right [09:27:47] <kshishkov> superdump: they need it only to read/write, not for tech support [09:27:51] <superdump> i'm normally pretty good at copying sounds people make just from hearing them though [09:28:31] <superdump> he said he'd probably only spoken english for a couple of hours total in his entire life [09:28:35] <kshishkov> superdump: have you tried http://www.slayradio.org/mastering_swedish_lesson_3.php ? [09:28:39] <superdump> and i still had a full conversation with him [09:28:46] <superdump> i still haven't listened to that [09:29:18] <kshishkov> SkÃ€ms! [09:29:26] <merbzt> it's awesome [09:29:57] <kshishkov> indeed [09:31:11] <kshishkov> not that I can use it in everyday conversation though [09:31:36] <superdump> listening [09:31:41] <superdump> 'are sheep allowed on the plane' [09:32:24] <kshishkov> no, try lesson 3, it's the hardest [09:33:10] <superdump> i'm normally lazy and don't make the swedish extra bit on 'i' and 'y' [09:33:20] <superdump> the cute throat bit [09:33:40] <superdump> that we normally make in english when we're being silly and pretending to be very young [09:34:18] <kshishkov> go for lesson 3, it features Swedish-only sounds [09:37:11] <superdump> jag lyssnar nu, or whatever the correct grammar is [09:37:50] <kshishkov> seems correct [09:38:00] <superdump> lol [09:38:08] <superdump> scottish people shit gelatine and cheddar [09:38:22] <superdump> (yel-ah-teen and shedd-ahr) [09:38:44] <kshishkov> it's not quite "sh" sound though [09:38:48] <superdump> i know [09:39:19] <kshishkov> that's the trickiest thing for me, the rest of sounds sounds fine [09:40:33] <superdump> some are more of a sh sound and some are more of a 'noise' sound made by narrowing the flow of air between your tongue and the roof of your mouth [09:40:51] <superdump> you can hear the guy (boz?) gets it [09:41:23] <superdump> like clearing your throat but in your mouth [09:41:34] <kshishkov> the second sound is something closer to "ch" [09:42:01] <superdump> not in the british way of making the ch sound [09:42:08] <superdump> which is not 'sh' [09:42:25] * superdump has seen a number of swedish adverts punning on the sound of 'ch' [09:42:49] <superdump> like 'cheap' and 'sheep' sounding the same [09:42:53] <superdump> which they don't [09:43:01] <kshishkov> well, you can think of it like the sound in true Japanese "ã" [09:43:16] <kshishkov> or short Russian "Ñ" [09:43:36] <superdump> but some people say 'kan-sher' and others say 'kan-<the noise>' [09:43:42] <superdump> swedish people [09:43:58] <kshishkov> could be [09:46:06] <superdump> they do, i've heard it [09:46:53] <superdump> sometimes it would make more sense to me to say 'sh' as then the word would more closely resemble the english word [09:46:59] <superdump> but i like the new sound :) [09:47:14] <superdump> i sound like an idiot if i try to make the 'i' sound properly though [09:47:32] <superdump> consistently while talking i mean [09:49:10] <twnqx> heh, from kernel 2.6.33.1 changelog [09:49:11] * kshishkov has noted that Swedes speak better English than in English-speaking countries [09:49:13] <twnqx> GCC 4.5 introduces behavior that forces the alignment of structures to [09:49:13] <twnqx> use the largest possible value. The default value is 32 bytes, so if [09:49:13] <twnqx> some structures are defined with a 4-byte alignment and others aren't [09:49:13] <twnqx> declared with an alignment constraint at all - it will align at 32-bytes. [09:49:26] <twnqx> caused non-booting kernels :P [09:50:09] <kshishkov> way to go [09:50:24] <kshishkov> maybe Linus finally will start compiler project [09:50:41] <twnqx> yeah, seems it can "result in a non-standard array" [09:51:23] <superdump> kshishkov: for the most part yes :) [09:51:34] <superdump> maybe the accent is more consistent than accents in england [09:51:59] <kshishkov> and it doesn't have Scotland [09:52:54] <superdump> :) [09:53:04] <superdump> kshishkov: maybe look on youtube for rab c nesbit videos [09:53:08] <superdump> see if you can understand him [09:53:32] <kshishkov> superdump: forgot to add that long time ago Sweden controlled Scotland though [09:55:10] <kshishkov> what's the problem? I've watched MPFC without almost any problem [09:55:27] <superdump> what's that? [09:55:42] <kshishkov> Monty Python's Flying Circus [09:55:49] <kshishkov> and it featured Gumbies [09:56:15] * Kovensky never saw anything monty python [09:56:22] * Kovensky feels that he should but is too lazy [09:56:44] * kshishkov drops 16ton weight on Kovensky [09:56:48] <Kovensky> and I guess I should join the fad and study swedish too but I guess I lack time :S [09:57:31] <kshishkov> no since you don't belong to Swedish FFmpeg developers group [09:57:38] <Kovensky> not like I'm really busy but I really should be studying my maths / physics / chemistry (just HS level!) for the upcoming test in july :S [09:57:55] <Kovensky> kshishkov: I want to go to sweden, does that count? :X [09:58:10] <superdump> kshishkov: http://www.youtube.com/watch?v=Nrmcxa1yBec [09:58:12] <superdump> for example [09:58:17] <superdump> he's the guy in the string vest [09:58:24] <Kovensky> hmm, I guess not, I'm still missing the "FFmpeg developer" part [09:58:44] * Kovensky can't do maths to save his life :V [09:58:52] <twnqx> :S [09:59:34] <astrange> i always forget the procedures when i have to take tests [10:01:12] <Kovensky> heh [10:01:21] * Kovensky *really* needs to study physics / chemistry [10:01:51] <elenril> look at you still talking when there's science to do [10:02:00] <Kovensky> since I didn't study those during high school (we had no physics teacher for like 2/3 of HS, and the chem teacher was useless) [10:02:06] <Kovensky> elenril: :P [10:02:24] <Kovensky> well, time for me to not skip class today [10:02:33] <Kovensky> aka time for my daily battle for catching a bus at all :V [10:02:39] * KotH should study math and psychology [10:02:42] * Kovensky is off [10:03:12] <elenril> btw why isn't metadata writing for ogg/flac applied? [10:03:14] * KotH is on [10:03:27] <elenril> KotH: why don't you do it =p [10:03:49] * KotH isn't an ffmpeg developer [10:03:58] <elenril> you don't have commit rights? [10:04:11] <astrange> 3905 dezicycles in decode_residual, 2096825 runs, 327 skips -> 3903 dezicycles in decode_residual, 2096812 runs, 340 skips [10:04:25] <astrange> how do you interpret changing skips, run it over again until it stops? [10:04:46] <KotH> elenril: i didnt say that i dont have commit right, i just said that i'm not a developer [10:06:07] <elenril> you have commit rights -> you can apply approved stuff [10:06:17] <elenril> doesn't really matter if you're a developer or not [10:08:58] * elenril wonders if chapters should only be copied by default when there's one output file [10:09:34] <astrange> what other numbers of output files are there? [10:10:10] <elenril> you can have tons of output files [10:14:15] <av500> elenril: one could adjust chapter timestamps from multiple input files to multiple output files [10:15:11] <elenril> av500: that's not something ffmpeg can reasonably guess [10:15:15] <astrange> hmm [10:15:26] <astrange> i think it makes sense to copy to everything [10:15:29] <elenril> i'm only talking about what it should do by default [10:15:44] <av500> elenril: why guess? [10:16:02] <av500> ffmpeg should know what output timestamp belongs to what input file, no? [10:16:41] <av500> elenril: btw, I would like to have an autochapter feature in ffmpeg [10:16:50] <av500> like, create a chapter every 10min [10:16:55] <twnqx> superdump: will 8G /tmp be enough? [10:17:05] <elenril> av500: send patches ;) [10:17:09] <superdump> not sure [10:17:13] <av500> elenril: yes, I prolly will [10:17:21] <superdump> you'll have to ask janne [10:17:26] <av500> I also have ffplay skip to chapters on PGUP/PGDOWN [10:17:27] <superdump> but for now you could try it [10:17:37] <superdump> have a go at 05_throwing-04 [10:17:42] <twnqx> and: who is the "me" in "notify me of the jobs you took" [10:17:45] <twnqx> ok [10:17:47] <av500> janneg: [10:17:51] <superdump> right [10:17:54] <av500> twnqx: janneg [10:18:05] <twnqx> eh, throwing 04 isn't there any more :P [10:18:13] <superdump> oh, cos i have it :) [10:18:15] <superdump> e-mail? [10:18:43] <superdump> /query as you please [10:35:34] <astrange> http://github.com/astrange/ffmpeg/commit/48ff55fc9f3f393633f4e24b0bb8658f72… huh, i can't get this to make any difference now that i try it again [10:35:41] <astrange> across two gccs and clang [10:48:57] <kshishkov> superdump: seems quite easy to understand, any examples of Welsh accent? [10:50:02] <j-b> Good morning [10:50:43] <kshishkov> bonjour [10:51:02] <av500> 'jour [10:55:26] <superdump> kshishkov: just search youtube [10:55:36] <superdump> rab c nesbitt is not easy to understand at all [10:55:56] <kshishkov> why? [10:56:05] <superdump> because he doesn't pronounce things [10:56:09] <superdump> he slurs them all together [10:56:17] <superdump> signal to noise ratio is very very low [10:56:36] <superdump> if you speak like him, don't expect to be understood [10:56:37] <kshishkov> you've not heard local people who think they know English [10:56:49] <superdump> local where? [10:57:11] <kshishkov> eastern europe [10:57:38] <superdump> well, don't expect english natives to understand you [10:57:44] <superdump> if you sound like rab [10:58:22] <kshishkov> I'll move to the land of unicorn then [10:59:22] <superdump> watch english/american tv, pick an accent you like, copy it :) [10:59:27] <kshishkov> I think the only useful phrase for people like me is "spare a bob, guv" [10:59:43] <superdump> i don't think so [10:59:51] <superdump> you're highly skilled [11:00:07] <superdump> you should be able to get a job [11:37:00] <av500> j-b: u at "solutions linux"? [11:37:28] <j-b> I was, yesterday. But VideoLAN has a stand [11:37:35] <j-b> av500: you are going there? [11:37:59] <av500> j-b: no [11:38:10] <av500> I just saw u have a booth [11:38:39] <j-b> yes, we do. We offer candy and Soda :D [11:38:48] <j-b> So our booth is popular [11:39:19] <kshishkov> you should offer striped ice cones [11:39:56] <thresh> or strippers with cones [11:40:32] <av500> j-b: the booth is not hidden behing video wall :) [11:42:41] <janneg> twnqx: thanks [11:44:12] <twnqx> janneg: my blender produces openexr instead of png, is that a problem? :P [11:44:37] <janneg> superdump: it's strange, I'm rendering 05_throwing-02 now and it doesn't use more than 6G [11:44:58] <kshishkov> wrong Blender version then [11:45:02] <superdump> it's probably just the scene [11:45:12] <superdump> well maybe i can grab an older blender [11:45:16] <janneg> twnqx: that wouldn't be a problem but I suspect you're also not rendering the correct resolution [11:45:30] <twnqx> :o [11:45:47] <superdump> twnqx: did you download the render_settings.py and overwrite the one in production/scripts/ ? [11:46:26] <janneg> do you have the render_settings.py from my server in production/scripts/ [11:46:39] * twnqx rm -rf's render [11:47:43] * twnqx makes up for that by rendering two sets in parallel since 800% was never exceeded [11:48:33] <kshishkov> don't forget RAM [11:48:53] <twnqx> i'll add 16G swap to the 16G physical [11:49:32] <superdump> if it starts swapping it'll be hella slow [11:49:37] <janneg> twnqx: don't. it will makes things just slow and 8G per frame should be enough [11:49:43] <kshishkov> so it saves CPU power, see? [11:49:48] <superdump> :) [11:53:15] <twnqx> cpu frequency scaling takes care of that :P [11:56:47] * kshishkov curses at debian having less not installed by default [11:57:33] <twnqx> lol [11:57:38] * thresh just doesnt understand who uses 'default' distros [11:57:52] <janneg> not having more not installed by default would be a bigger problem? [11:57:57] <janneg> ;0 [11:58:40] <kshishkov> thresh: lazy people who just try it instead of installing it permanently [12:01:19] <twnqx> lol [12:01:23] <twnqx> linux kernel sucks [12:01:27] <twnqx> all cpus @ 100% [12:01:34] <twnqx> but no, cpu freq stays at 100 MHz [12:01:37] <twnqx> 1100* [12:01:43] <kshishkov> wait for GNU Hurd [12:02:07] <kshishkov> and maybe run cpufreq-info [12:02:13] <bilboed-pi> twnqx, running as nice ? [12:03:31] <twnqx> i just forced all cpus to max speed [12:03:50] <twnqx> and yeah, i hate that the kernel ignores the load of niced processes [12:04:26] <twnqx> also [12:04:30] <twnqx> box is stalled [12:04:34] <twnqx> deleting a file >_> [12:04:35] <thresh> :-) [12:04:47] <bilboed-pi> twnqx, yay for io schedulers :) [12:04:50] <kshishkov> overheated? [12:04:57] <twnqx> no [12:05:04] <twnqx> sd 10:0:0:0: [sdi] Very big device. Trying to use READ CAPACITY(16). [12:05:05] <twnqx> sd 10:0:0:0: [sdi] 13375635456 512-byte logical blocks: (6.84 TB/6.22 TiB) [12:05:09] <twnqx> Oo funny messages [12:05:33] <kshishkov> it will be funnier in 10 years [12:05:39] <thresh> too old. [12:06:27] <twnqx> i don't think the device is THAT big, even for today [12:06:34] <twnqx> especially since it's iscsi [12:06:43] <thresh> not a home machine, though: /dev/mapper/vg-lv00 20T 15T 5,7T 72% /var/lib/vz [12:07:02] <twnqx> yeah, exactly [12:07:05] <thresh> plus three others, around 8T each ... [12:07:06] <twnqx> it's not that big [12:07:15] <thresh> yeah, it's been there for 3 or so years already [12:07:39] <twnqx> never noticed it before [12:07:46] <janneg> twnqx: which cpufreq governor? which kernel? my ondemand has a ignore_nice_load file in sysfs which is set to 0 [12:07:53] <twnqx> ah! [12:07:58] <twnqx> yes, it was ondemand [12:08:54] <twnqx> and i need to change some things... a) hardware raid controller, b) hardware crypto accelerators [12:24:34] <twnqx> janneg: does that file only exist when ondemand is active? [12:25:41] <twnqx> hm, janneg, my ignore_nice_load is 0 too, yet the cpus stay at 1.1ghz [12:41:14] <twnqx> superdump: 18 minutes per frame now :S [12:45:27] <janneg> twnqx: it works as intended here with 'nice -n 19 burnP6' [12:51:24] * KotH needs more numbercrunching machines [12:54:36] <twnqx> what for? [12:54:51] <KotH> BBB and cracking passwords [12:54:59] <twnqx> just get a mssive array of beagleboards [12:55:14] <av500> a BBB-BB array [12:55:18] * KotH doesnt think that most of the heavy stuff runs on a BB [12:55:32] <twnqx> just use swap on nfs [12:55:34] <twnqx> or iscsi [12:55:38] <KotH> lol [12:55:53] <KotH> or just wait 10y for BBv23 [12:55:59] <thresh> swap on iscsi. [12:56:06] <thresh> oh joys of 21 century [12:56:08] <MrNaz_out> awesome! my baklava just arrived [12:56:12] * MrNaz_out dccs the plate around [12:56:32] * twnqx grabs some pieces [12:56:41] <twnqx> thanks! [12:56:42] <KotH> hey! dont klog my tubes with all that suggar! [12:57:23] <MrNaz_out> KotH it's ok, your series of tubes can be cleared with a little exercise [12:57:48] * av500 prefers baklava with less sugar and more nuts [12:58:08] <MrNaz_out> av500 this has walnuts in the base and crushed pistacio on top [12:58:21] * KotH preferes baklava that has not traveled around the globe...twice [12:58:23] <av500> accepted [12:58:51] <av500> the stuff availabel here is mostly sugar water :( [12:59:03] <twnqx> poor av500 [12:59:06] <KotH> av500: i feel your pain... [12:59:14] <twnqx> i'll get you some next time i'm in saudi [12:59:30] <av500> twnqx: thx! [12:59:33] <twnqx> usually i only grab a few kg of almond-stuffed, chocolate-covered dates [12:59:45] <MrNaz_out> twnqx you work in saudi? [12:59:56] <twnqx> i lived there until december :P [13:00:01] <twnqx> still have a residency visa [13:00:03] <MrNaz_out> almost-chocolate dates are awesome [13:00:10] <MrNaz_out> i lived there in 1994 for a year [13:00:13] <MrNaz_out> i was 14 years old [13:00:18] <twnqx> poor you :P [13:00:19] <MrNaz_out> man... talking about 1994 makes me feel old [13:00:24] <MrNaz_out> on wait... i *am* old [13:01:12] <KotH> lol [13:05:23] <CIA-92> ffmpeg: benoit * r22581 /trunk/libavcodec/qtrleenc.c: [13:05:23] <CIA-92> ffmpeg: qtrleenc: add rgb555 output [13:05:23] <CIA-92> ffmpeg: Patch by Alexis Ballier std_gmail_addr(name.surname) [13:06:39] * KotH wonders who'll be able to decode this email adr in 20y, when gmail will be long gone [13:07:06] <av500> they can look it up in bing-archive [13:08:17] <MrNaz_out> KotH the IT staff at that time will need to confer with the village elders [13:08:40] <av500> they will have to negotiate for generator fuel as well [13:08:40] <MrNaz_out> in 20y from now we'll have gotten ww3 out of the way and will be well on our way to rediscovering the wheel [13:09:35] <MrNaz_out> ive been stockpiling manuals on assembler so when we re-invent the 8086 microprocessor i'll have a huge head start! [13:09:45] <KotH> lol [13:10:34] * av500 files an A20 gate patent to be applied in 19ys... [13:11:00] <MrNaz_out> that's assuming the patent office survives the coming war [13:11:06] <MrNaz_out> i'm hoping it doesnt [13:11:12] <MrNaz_out> i plan on patenting yoyos [13:11:32] <av500> MrNaz_out: they will reopen that 1st thing after the war [13:11:33] <mmu_man> hmm it should be doable with IPOT [13:11:43] * mmu_man pets IP Over Time [13:13:49] * KotH notes that this should be made into an RFC... in a non-french language [13:14:10] <MrNaz_out> with x264 and ffmpeg now being codependent, installing either is now a gigantic pita [13:14:18] <jai> av500: they might even run a makeshift one out of the trenches during the war... [13:14:36] <MrNaz_out> jai how would they enforce patents? [13:14:51] <jai> MrNaz_out: shotguns ofcourse [13:15:14] <MrNaz_out> im imagining a fat lawyer jumping up and pointing at an incoming shell and yelling "HEY! NO FAIR! THAT STABILIZOR FIN DESIGN IS PATENTED!" [13:15:53] <jai> lul @ fat lawyer [13:16:28] <av500> MrNaz_out: no, they will ambush the supply trewck and confiscate the shells with a subpoena :) [13:16:40] <Kovensky> lol [13:17:29] <MrNaz_out> yea, the enemy soldiers will end up having to spend their r&r time working to pay off the IP infringement fine [13:17:41] <MrNaz_out> i think we've just confirmed it: [13:17:49] <MrNaz_out> lawyers are the ultimate weapon for waging war [13:18:05] <MrNaz_out> however, i'm sure that there's a geneva convention about that [13:18:26] <av500> MrNaz_out: there is a reason why the US airdrops lawyers right after bunker busters... [13:19:42] <jai> lmao [13:20:20] <av500> now, if they would airdrop them together.... [13:20:51] <MrNaz_out> av500 now i know that the bunker nudter bombs are inanimate objects, but there's no reason to be cruel to them in their last moments of existence [13:20:57] <MrNaz_out> buster* [13:25:56] <MrNaz_out> errr [13:26:05] <MrNaz_out> Ron? i cant find your patch buddy... [13:27:41] <MrNaz_out> wow speak of the devil [13:27:48] <MrNaz_out> BBB [13:27:53] <BBB> ? [13:27:56] <MrNaz_out> i dont see a posting from you on the mailing list [13:28:17] <MrNaz_out> with that patch [13:28:18] <BBB> Fix FFM-based audio streaming from FFmpeg to FFserver [13:28:30] <BBB> it's there [13:28:39] <MrNaz_out> ffserver-users ? [13:28:54] <BBB> huh? is that a mailinglist? [13:28:56] <jai> hmm, did my matroska muxer patch get lost somewhere [13:28:57] <BBB> no, ffmpeg-devel [13:29:00] <MrNaz_out> aah [13:29:01] <MrNaz_out> k [13:29:02] <jai> Yuvi: ^ [13:29:07] <BBB> this is a development question in ffmpeg itself [13:29:09] <BBB> :) [13:29:15] <BBB> btw I'm not on ffserver-users [13:29:17] <BBB> maybe I should be [13:29:33] <jai> BBB: or you could just read the archives... [13:29:34] <MrNaz_out> BBB yea i petitioned for a ffserver ML a while back and got it... its proven quite useful (although i havent managed to help anyone for a few months now due to lack of time:( ) [13:30:08] <jai> that reminds me, havent been to #ffmpeg in a while [13:30:17] <MrNaz_out> BBB nvm once -head gets to a working state i'll start by writing a ffserver zero to basic working guide and use that as a starting point to do support for ffserver [13:32:58] <BBB> great [13:33:06] <BBB> I'll look at the archives to see if I'm missing something [13:33:12] * BBB is not on ffmpeg-users@ [13:50:27] <MrNaz_out> BBB i *think* the audio was the only outstanding issue [13:51:10] <MrNaz_out> i'm compiling now, if audio is fixed then i believe ffserver is in a currnelty working state with all extra functionality that i've requested over the past year or so [13:57:58] <DonDiego> superdump: do you accept aac bug reports these days or should i direct them all to peloverde? [14:01:54] <superdump> put them on roundup, then whoever wants and has time to can look at them [14:02:53] <DonDiego> i'd like to quickly discuss them here on irc first [14:03:10] <DonDiego> i'll wait until the two of you are around [14:03:24] <superdump> well you can say it now if you want [14:06:14] <DonDiego> i was just testing the samples collection and noticed a few things [14:06:34] <superdump> such as...? [14:06:38] <DonDiego> let's talk about this later, i need to run out anyway [14:06:50] <DonDiego> bbl [14:07:46] <superdump> ok [14:11:24] <kshishkov> is there any kind of horoscope to predict where you three will meet? [14:12:07] <mru> who three? [14:12:47] <kshishkov> DonDiego and two people who he wanted to talk to about AAC [14:13:11] <BBB> MrNaz_out: don't forget you need the FFM patch also [14:13:29] <BBB> MrNaz_out: [PATCH] fix the SAMPLE_FMT_NONE case in ffmdec.c [14:13:33] <BBB> that thread [14:13:39] <BBB> otherwise the FFM file itself is invalid [14:14:06] <MrNaz_out> oh there's two patches? [14:14:22] * MrNaz_out looks again [14:27:28] <BBB> MrNaz_out: let me know if you cannot find it [14:27:57] <MrNaz_out> BBB i can see the one thread [14:28:20] <BBB> there's a one-liner patch for ffmdec.c [14:28:27] <BBB> and somewhat bigger patches for ffserver.c/ffmpeg.c [14:28:34] <MrNaz_out> and i have the patch from that one... which are the two files? i only see fix-ffm-no_sample_fmt.patch [14:29:17] <BBB> the other one is in the other thread I just pointed out [14:29:29] <BBB> "Fix FFM-based audio streaming from FFmpeg to FFserver" [14:30:16] <MrNaz_out> i dont suppose i could be a total pain in the ass noob and ask you to email them all to me so i know which ones are the right ones? there's a few versions there and it's not clear to me which one is the latest as the thread branches off in a few places and theres different versions and fixes along the way [14:30:39] <BBB> they all work, they're just under review [14:30:45] <MrNaz_out> ok [14:30:47] <BBB> so you can pick any one [14:30:55] <BBB> they do the same thing, but differently [14:33:28] <MrNaz_out> got e, [14:33:29] <MrNaz_out> em [14:33:32] <MrNaz_out> compiling now [14:43:51] <CIA-92> ffmpeg: mru * r22582 /trunk/common.mak: [14:43:51] <CIA-92> ffmpeg: Make ranlib silent in brief output mode [14:43:51] <CIA-92> ffmpeg: Running ranlib is quick and uninteresting, no need to print it. [14:43:53] <CIA-92> ffmpeg: mru * r22583 /trunk/subdir.mak: [14:43:53] <CIA-92> ffmpeg: Remove $(MSG) override for install-lib targets [14:43:53] <CIA-92> ffmpeg: This is no longer needed and causes incorrect output in some cases. [14:44:40] <roozhou> hi, anyone knows how to set internal time_base in frame copy mode? [15:04:27] <MrNaz_out> BBB you still here? [15:04:40] <MrNaz_out> if you are http://www.ymatv.com/?watch&res=high i think i can say that those patches work :) [15:05:54] <jai> you patched your production server?? [15:06:14] * av500 wonders why he is spying on right now... [15:06:45] <av500> why->who [15:07:16] <CIA-92> ffmpeg: cehoyos * r22584 /trunk/libavcodec/h264dsp.c: Fix compilation on PPC 470. [15:12:47] <BBB> MrNaz_out: thanks for confirming! :) [15:15:11] <MrNaz_out> BBB dont suppose you want to help me get the h264 params right do you? :) [15:15:25] <BBB> no h264 hero here, sorry [15:15:33] <BBB> you want to ask dark_shikari [15:15:41] <CIA-92> ffmpeg: rbultje * r22585 /trunk/libavformat/ffmdec.c: [15:15:41] <CIA-92> ffmpeg: Cast sample_fmt (as read from bitstream as a 16-bit value) to int16, so that [15:15:41] <CIA-92> ffmpeg: negative values, e.g. SAMPLE_FMT_NONE (-1), are read correctly also. [15:18:43] <kierank> MrNaz_out, what about h.264 do you need to know? I might be able to help [15:19:24] <MrNaz_out> kierank ive got a ffserver config file with some h264 settings in it [15:21:55] <MrNaz_out> http://pastebin.com/WQNd8z5u <-- that's the conf i have right now... [15:22:01] <MrNaz_out> for stremaing, can you recommend any changes ? [15:25:10] <kierank> bufsize is a bit big [15:26:16] <kierank> but you might want it like that [15:28:52] <MrNaz_out> kierank when you watch the stream, do you get pauses? http://www.ymatv.com/?watch&res=high [15:29:12] <MrNaz_out> when i watch it here it's pausing every so often as though to buffer [15:29:49] <kierank> yes [15:29:55] <MrNaz_out> see [15:30:07] <MrNaz_out> i dont get that with the old version [15:30:30] <kierank> reduce bufsize to something more reasonable [15:30:46] <MrNaz_out> such as? [15:31:15] <kierank> 300-500k [15:31:30] <MrNaz_out> i thought that bufsize had to be bitrate * buffer length [15:31:37] <MrNaz_out> in this case, i want 4 seconds worth of buffer [15:31:59] <kierank> then what you have is ok if you want 4 seconds of buffer [15:34:02] <BBB> peloverde: it's an iterative wiener filter, if you want to test your google skills, I figured that out yesterday [15:34:10] <BBB> there's some good papers on it [15:36:49] <peloverde> glad to hear you figured it out [15:37:00] <MrNaz_out> BBB dont suppose you could offer some shell scripting advice? [15:37:09] <BBB> I can try [15:37:22] <BBB> peloverde: thanks for the repeated hints at hilbert, that helped a lot [15:37:58] <BBB> MrNaz_out: what exactly do you need? I'm not a shell-scripting hero, but know a little [15:38:30] <mru> don't we have any resident shell gurus here? [15:39:09] <BBB> you [15:39:12] <BBB> and dondiego [15:39:14] <MrNaz_out> BBB http://pastebin.com/bpRdbVYV currently that's my script to feed ffmpeg... however, if there are any network latency issues or for some other reason ffmpeg is held up... the resulting stuttering occurs in the grabbed dv file as well... is there any way to ensure that the dvgrab and tee part of that command are not affected by whatever happens with ffmpeg? i think a fifo could work but my script-fu is nowhere near good enough [15:39:15] <BBB> more than me at least [15:39:42] <MrNaz_out> well my question is open to all :) [15:42:35] <mru> dvgrab loses frames if the pipe blocks? [15:43:55] <MrNaz_out> yea [15:44:33] <MrNaz_out> well [15:44:43] <MrNaz_out> it could be that tee is what actually loses the data [15:44:56] <mru> dvgrab -f dv1 >"$fname" & [15:45:08] <mru> tail -c+1 "$fname" | ffmpeg -i - ... [15:45:17] <mru> tee never loses data [15:45:37] <mru> but if its output blocks, the input will block [15:46:15] <MrNaz_out> so if ffmpeg blocks then that will cause tee's input to block ? [15:46:28] <mru> once the pipe buffers fill up, yes [15:46:37] <mru> the pipe buffers are typically a few k [15:47:24] <MrNaz_out> mru http://pastebin.com/0hnKB8Ab so that will prevent ffmpeg blocks from killing dvgrab's output ? [15:48:02] * peloverde scratches his head at some of the stranger SBR bug reports [15:48:20] <mru> MrNaz_out: that runs dvgrab and ffmpeg independently [15:48:46] <mru> it might fail if tail polls the file too infrequently [15:49:11] <mru> you could always cook your own tee-like app with two threads and bigger buffers [15:50:41] <DonDiego> peloverde: nice to see you are around.. [15:50:52] <DonDiego> peloverde: have you already tested all the samples from our collection? [15:51:10] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/ [15:51:26] <peloverde> yes [15:52:52] <DonDiego> i found some issues [15:53:01] <peloverde> which files? [15:53:10] <DonDiego> superdump: ping [15:53:18] <DonDiego> let me run through the lot of them.. [15:53:20] <superdump> pong [15:53:47] * superdump is expecting a bunch of channel config related crap for invalid files [15:54:59] <DonDiego> gah, give me a sec i need to pull the samples [15:55:03] * DonDiego is at work [15:55:07] <MrNaz_out> mru that does not work when i need to use sudo [15:55:10] <DonDiego> psssst! ;) [15:55:29] <mru> MrNaz_out: huh? [15:55:36] <MrNaz_out> http://pastebin.com/6vX7XQD8 [15:55:48] <mru> and? [15:55:57] <MrNaz_out> prolly easier if i paste [15:56:21] <mru> you really shouldn't be running stuff as root [15:56:29] <mru> why does dvgrab need to be root? [15:56:47] <MrNaz_out> http://pastebin.com/yQ7mtycx [15:57:26] <bilboed-pi> chmod a+x /dev/raw1394 (or whatever the device is) should avoid having to run dvgrab as root [15:57:31] <MrNaz_out> dvgrab needs to be root coz it accesses raw1394 and a few other devices that require root... i'm not entirely sure, but a year ago when i was first setting all this up i spent the best part of 4 hours trying to get around that [15:57:39] <bilboed-pi> s/a+x/a+rwx/ [15:57:45] <mru> bilboed-pi: why x? [15:57:47] <MrNaz_out> bilboed-pi can you chmod a device like that? [15:57:51] <bilboed-pi> MrNaz_out, sure [15:57:56] <mru> surely you don't want to _execute_ the dv data [15:58:06] <MrNaz_out> i seem to recall that not working... let me try again [15:58:19] <mru> MrNaz_out: your ffmpeg is old [15:58:23] <mru> it's missing a fix from last night [15:58:25] <bilboed-pi> mru, I did encounter a case when it needed to have the executable bit set :( [15:58:34] <av500> mru: if you points the camera at a code printout, it might work [15:58:45] <MrNaz_out> mru 48 hours is old these days? shit eh... [15:58:56] <mru> 48h is ancient [15:59:13] <mru> we're talking 18h here [15:59:37] <MrNaz_out> in related news, the ffmpeg scene starts talking in l33t and referring to patches as "0day" [15:59:44] <av500> tversity looking for ffmpeg codec wrappers..... maybe openmax :) [16:00:19] <jai> av500: did you ask what exactly they have in mind? [16:00:26] <mru> oh, and tail needs a -f flag [16:00:46] <av500> jai: no, its on the ml [16:01:10] <MrNaz_out> mru so tail -c+1 -f "$fname" ? [16:01:17] <mru> should work [16:01:59] <jai> av500: ah, i see you replied [16:02:10] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/8_Channel_ID.m4a [16:02:14] <DonDiego> let's start here [16:02:22] <DonDiego> ffplay tells me it cannot open codecs [16:02:35] <DonDiego> but mplayer has no problems (with lavf demuxer) [16:02:52] <jai> sdl sucks [16:02:53] <peloverde> DonDiego: FFplay doesn't work on my system [16:03:49] <av500> peloverde: and that cannot be fixed? [16:03:51] <jai> you could test with alsa i think [16:03:55] <superdump> i'll give it a go in a sec [16:04:10] <mru> DonDiego: that's an ffplay/sdl bug it seems [16:04:19] <jai> yep [16:04:31] <jai> same goes for a bunch of truehd samples we have [16:04:36] <av500> 8_Channel_ID.m4a: could not open codecs [16:04:37] <mru> the file plays fine with non-sdl players [16:04:49] <mru> the error message should probably be improved [16:05:46] <DonDiego> [aac @ 0x26ab710]max_analyze_duration reached [16:05:46] <DonDiego> [aac @ 0x26ab710]Estimating duration from bitrate, this may be inaccurate [16:05:52] <DonDiego> several files print this stuff [16:06:04] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/ct_faac-adts.aac [16:06:07] <DonDiego> this one for example [16:06:08] <peloverde> DonDiego: That isn't the AAC decoder [16:06:20] <peloverde> that's the probes [16:06:52] <DonDiego> it's still your area :) [16:06:52] <peloverde> Or demuxer [16:07:07] <peloverde> No it isn't, it's a techincal limitation of the ADTS format [16:07:18] <DonDiego> but do we need the spam? [16:07:35] <DonDiego> if it will get printed for every adts file, it's pointless [16:07:37] <jai> bump up the max_analyze_duration vaue [16:07:40] <jai> *value [16:08:48] <peloverde> ADTS doesn't have any sort of size field, for VBR ADTS the only way to get the length is to decode the whole file [16:09:17] <DonDiego> fine, but do we need to be informed about this for every file? [16:09:27] <peloverde> That error is printed in libavformat/utils.c, complain to said maintainer [16:09:41] <peloverde> I find it useful to know that the size estimate may be wrong [16:09:48] <av500> mru: so the issue is that avctx->request_channels asks for 2, but the codec is not able to fullfill that and still delivers 8, then SDL fails [16:09:53] <peloverde> It doesn't print it every frame [16:09:59] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/faad2-fail.mkv [16:10:02] <jai> the reason its verbose is because people complain about duration being incorrect [16:10:06] <DonDiego> this one is seriously broken [16:10:19] <roozhou> peloverde: iirc frame length is stored in ADTS header [16:10:25] <DonDiego> sound is played much too slowly [16:11:08] <peloverde> roozhou: kind of, the frame length in samples is always 1024 samples, except when it's not :), the issues is the total number of frames [16:12:12] <roozhou> peloverde: i mean the size of frame in bytes [16:12:29] <peloverde> DonDiego: faad2-fail plays fine for me [16:12:42] <roozhou> why do we need to DECODE the frame? [16:13:03] <jai> roozhou: he said decode the _file_ [16:13:45] <roozhou> better call it "parse the file" [16:13:59] <mru> DonDiego: that file plays just fine here [16:14:24] <jai> roozhou: i think we understood what he meant [16:16:30] <peloverde> I meant parse [16:16:50] <roozhou> can anyone help me with time_base issues in frame copy mode? [16:16:52] <peloverde> You can't get the channel count without decoding [16:18:40] <roozhou> ffmpeg -i input.mkv -vcodec copy -an output.flv [16:18:40] <roozhou> ffmpeg -i input.mkv -vcodec copy -an output.mp4 [16:18:40] <roozhou> I get different time_base, why? [16:19:04] <peloverde> But I'm not seeing an issue with "ffmpeg -vn -i faad2-fail.mkv out.wav" [16:19:27] <av500> mru: peloverde: it plays too slow here [16:20:28] <mru> av500: up to date ffmpeg? [16:20:48] <av500> rebuilding [16:21:01] <av500> it was *cough* yesterdays [16:21:44] <peloverde> I imagine yesterday's should be good [16:21:54] <av500> still to slow [16:22:08] <mru> get a faster computer :-) [16:22:27] <av500> right, there was this 6core I7.... [16:22:38] <av500> and it is a 6channel file, so it makes sense [16:22:50] <BBB> mru, MrNaz_out: bash has a buffer command for that [16:23:10] <BBB> at least in linux, it used to have something like that [16:23:16] <BBB> we used it a lot in mjpegtools for obvious reasons [16:23:22] <KotH> is anyone working on wma lossles? [16:23:39] <BBB> KotH: I thought jai was working on lossless [16:23:50] <mru> BBB: literally "buffer"? [16:24:01] <jai> KotH, BBB : on and off, yeah :) [16:24:16] <KotH> jai: do you have enough samples? [16:24:19] <jai> got busy because of postgrad applications :/ [16:24:34] <KotH> jai: or shall i extort some from all the users showing up in #mplayer that want wma lossless support? [16:24:38] <jai> KotH: yep, have the refernce encoder :) [16:24:40] <BBB> mru: IIRC yes, but doesn't work on my mac :) [16:24:49] <jai> KotH: people actually want wmals??? [16:24:57] <jai> i'm doing this for the kicks [16:25:11] <jai> err, *reference [16:25:12] <KotH> yeah tons of them [16:25:22] <KotH> about one per week or so [16:25:27] <jai> lol [16:25:48] <KotH> there was just one in #mplayer who was confused why his mplayer couldnt play that stuff [16:25:54] <peloverde> DonDiego, av500: is it proper speed if you decode to a file then play that? [16:26:03] <BBB> KotH: is wmavoice used at all? [16:26:08] <KotH> and complaining that he'd use ffmpeg if possible [16:26:11] <BBB> jai: upload it to the codecs repo so we can help [16:26:17] <BBB> I'd like to see how you do it also [16:26:26] <KotH> BBB: uhmm.. i think there were people who are using that too [16:26:26] <jai> BBB: sure thing [16:26:36] <av500> peloverde: as in? ffmpeg to something? [16:26:39] <merbzt> the music industry uses wmalossless also [16:27:09] <kierank> btw merbzt i have the wma pro over spdif spec if you don't have it [16:27:10] <jai> BBB: according to Facebook's user upload stats, wmavoice is quite rpevalent [16:27:13] <jai> *prevalent [16:27:27] <merbzt> kierank: send it to my email [16:27:52] * KotH wonders whether he should propose a patch that would collect codec usage data from mplayer [16:27:52] <peloverde> av500: as in "ffmpeg -vn -i faad2-fail.mkv out.wav", then "ffplay audio.wav" [16:29:21] <av500> peloverde: yes, still slow [16:29:46] <av500> let me play that on someting else [16:29:51] <BBB> jai: ok, cool [16:30:40] <av500> peloverde: out.wav is ok on PC with VLC [16:31:41] <BBB> jai: how is ralf going? [16:32:02] <peloverde> hmmm... that's strange [16:32:31] <av500> peloverde: I think the issue is SDL [16:32:51] <av500> if I play 6ch AC3, we request 2ch from decoder and get them, then SDL plays 2ch fine [16:32:55] <kierank> merbzt: anything else you want while i'm at it? [16:33:07] <av500> for this file, we request 2, but get 6 and SDL does not seem to handle that here [16:33:36] <peloverde> ac-3 has an in-codec downmix feature [16:33:39] <av500> yes [16:33:56] <av500> and it seems that this SDL here happily accepts 6ch, only to play it over 2, so 3x slow [16:35:00] <jai> BBB: also, slow :/ though i'm planning to get back to the pending stuff soon [16:35:12] <jai> BBB: done with admissions etc so should have free time [16:35:53] <BBB> ok, don't let me push you, just interested in the codecs themselves [16:35:54] <peloverde> That's probably what's happening [16:36:42] <jai> BBB: nah, i really need to get some stuff done :) [16:38:51] <jai> BBB: btw, i see that ralf is a gsoc project? [16:39:01] <BBB> oh, I added that [16:39:03] <BBB> nobody applied [16:39:07] <BBB> I was hoping you'd apply for it [16:39:18] <kierank> hmm seems i also have access to jpeg-xr specs [16:39:27] <jai> BBB: ah, technically i'm a student from august onwards so.. :) [16:40:32] <jai> anyway, there seem to be other tasks which should be more priority i guess [16:40:49] <jai> libavfilter audio support for example [16:43:15] <BBB> anything that you like :) [16:49:24] <nfl> hi im interested in the seeking api gsoc task. was wondering if yop demuxer/decoder is a good enough small task for this.. [16:52:38] <BBB> ait for bcoudurier, he will mentor that [16:52:40] <BBB> +w [17:09:54] <BBB> peloverde: when you have some time, could I ask you to review my complete postfilter patch to see if it looks sane to you? [17:10:16] <BBB> without tables, it's about 550LOC [17:15:54] <BBB> merbzt: same question for you, if you have time [17:18:59] <peloverde> BBB: I'm really trying to make some serious headway on PS today, I should have time tomorrow to give it a look [17:19:06] <BBB> ok, thansk [17:26:06] <superdump> ok, everyone form a wall around peloverde [17:35:43] <ramiro> there's someone on ffmpeg-user saying the native aac encoder is horrible. can we say it's still "experimental"? [17:36:26] <kshishkov> since peloverde changes have not hit SVN yet, it is experimental [17:36:32] <kshishkov> (and horrible) [17:36:49] <peloverde> yes, we can still say it's experimental [17:36:56] <peloverde> that's what the changelog entry says [17:37:06] <peloverde> I should have some time for it post PS [17:37:43] <ramiro> replied. [17:38:44] <kshishkov> it will be major piece of news when ffaacenc becomes non-experimental [17:38:53] <ramiro> kind of like vlc went 1.0? [17:40:27] <DonDiego> peloverde: ok, so it was an sdl problem [17:40:29] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/faad_infinite_long.aacp [17:40:39] <DonDiego> this one produces some serious console spam [17:40:48] <DonDiego> [aac @ 0x1a114d0]Parametric Stereo is not implemented. Update your FFmpeg version to the newest one from SVN. If the p [17:40:49] <peloverde> because it has serious errors [17:40:51] <DonDiego> roblem still occurs, it means that your file has a feature which has not been implemented. [17:41:07] <peloverde> DonDiego: people asked for that message during SBR review [17:41:09] <DonDiego> other similar messages are only printed once [17:41:34] <DonDiego> they did not ask for that message to be printed thousands of times :) [17:41:53] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/faad_infiniteloop.aacp [17:41:55] <DonDiego> same problem [17:42:18] <av500> DonDiego: the SBR message was also printed for every frame.... [17:42:19] <peloverde> ff_log_missing_feature("ff_log_missing_feature_once()", 0); [17:43:01] <DonDiego> peloverde: fix it :) [17:43:04] <DonDiego> http://samples.ffmpeg.org/A-codecs/AAC/Major%2006%20kwestia%2003.mka [17:43:11] <DonDiego> that sample also spams the console [17:43:21] <DonDiego> and i think it's not a broken file [17:43:57] <peloverde> The choices were log not at all, log every frame it happens, or someone else implement ff_log_missing_feature_once() [17:46:05] <peloverde> That file seems trashed to me, it's calling reserved SBR extensions [17:46:48] <kshishkov> reminds me of RealVideo [17:47:11] <kshishkov> if somewhere dquant is met, it means that file is broken [17:47:40] <av500> I always used the file extension to match for that :) [17:47:41] <kshishkov> it's valid bitstream syntax but no actual file is using it [17:49:42] <DonDiego> peloverde: well, it's annoying.. [17:49:43] <peloverde> Also that file reads past the end of SBR elements which is a serious issue [17:50:04] <peloverde> Then implement ff_log_missing_feature_once() and I'll be glad to change it [17:50:13] <DonDiego> :) [17:50:32] <DonDiego> i just ran through the list of samples today to doublecheck [17:50:51] <av500> av_log(c, AV_LOG_INFO | AV_LOG_ONCE, "foo"); ? [17:50:52] <DonDiego> and check what libfaad can do that ffmpeg can't [17:51:12] <av500> or av_log_once(c, AV_LOG_INFO, "foo"); [17:51:55] <astrange> http://pastebin.com/FZY9s2u5 [17:52:11] <astrange> but now i think it should just be another parameter to av_log_missing_feature() [17:52:45] <DonDiego> astrange: please submit this :) [17:53:34] <av500> once could even be default, no? [17:55:49] <peloverde> DonDiego: Do you have anymore information on where that file came from? it is very screwed up but seems to playback ok [17:56:19] <peloverde> My main complaint with the samples archive is that it never says where anything came from or what feature/bug it tests [17:56:50] <astrange> there are supposed to be .txt files for that but many are missin g [17:59:13] <DonDiego> no, i dunno where it came from [18:01:15] <peloverde> That file is seriously screwed up but it feels constructed [18:02:08] <DonDiego> astrange: also, what was it about ffmpeg2 being slow compared to libmpeg2? [18:02:21] <mru> nonsense [18:02:31] <mru> that was the case a long time ago [18:03:40] <astrange> it was 1s faster in my mplayer on a 30sec 1080p clip, but i noticed my mplayer is actually a month or two old [18:03:50] <astrange> not that mpeg12 has changed since then [18:04:10] <mru> try it on arm [18:04:15] <astrange> ffmpeg2 should be faster using the xvid idct or using threads, but those aren't default [18:05:25] <DonDiego> nobody doubts it's faster on arm, but it should be faster on x86 as well [18:05:38] <DonDiego> astrange: you said you knew how to speed it up... [18:06:02] <mru> someone should write ssssseeeeee3 asm for it [18:06:09] <mru> I'm sure something could be improved there [18:08:04] <astrange> i think some multiplies can be taken out of the C part before getting to that [18:08:21] <astrange> but sse2/4 simpleidct would help a lot, yes [18:08:44] <astrange> anyway they're still pretty close and ffmpeg2 is already the default, so i don't mind removing internal libmpeg2 [18:10:30] <BBB> DonDiego: you can surely fix up a patch that makes ff_log_missing_feature() only do that once [18:12:07] <astrange> i'm going with adding a 'once' parameter to it, but that has the side effect of adding NULL to every existing call [18:15:31] <mru> the alternative is to make it a macro [18:16:36] <BBB> make it a macro [18:16:38] <kshishkov> probably a macro - how else it will deal with static variables? [18:16:40] <mru> that could be done without breaking abi [18:16:43] <BBB> and always make it once [18:16:51] <BBB> I cannot imagine that you'd NOT want it to be once and spam the console [18:17:12] <kshishkov> you're not evil enough then [18:17:16] <mru> if some place really need that, it can override the macro by calling it as (func)(args) [18:17:17] <BBB> :) [18:17:24] <astrange> well, you have to add a context variable for every log if they're all going to be once [18:17:31] <mru> no [18:17:36] <astrange> it's either that or a hash table per log message [18:18:00] <kshishkov> yuck [18:18:07] <mru> #define blah() do { static int once; if (!once) blah(); once=1; } while (0) [18:18:13] <BBB> #define ff_log_missing_feature(ctx, bla, one_zero) { static int did = 0; printf(""); did=1; } [18:18:21] * BBB kicks mru [18:18:26] <BBB> you type faster, unfair [18:18:39] <kshishkov> type smarter, not faster :P [18:18:48] <BBB> ohyeah he added the if() [18:18:49] <BBB> :) [18:19:03] <mru> that's an essential part [18:19:03] <astrange> might be printed twice with threads. doesn't matter i guess [18:20:59] <BBB> astrange: indeed [18:21:25] <kshishkov> depends on number of tracks for that race condition [18:22:00] * BBB goes look for new project to RE [18:22:19] <BBB> jai does losslesses, wvp2 is for gsoc... [18:22:24] <kshishkov> VoxWare! Indeo Audio! [18:22:24] <BBB> what shall I do? [18:22:32] <BBB> indeo... yeah you mentioned that before [18:22:41] <BBB> I'll see what I think of it in a debugger [18:22:44] <jai> BBB: VP8 ;) [18:22:49] <kshishkov> voxware is more important though [18:22:52] <BBB> vp8 will be open soon, no reason to RE [18:22:54] <BBB> waste of time [18:23:00] <peloverde> ProRes, AIC? [18:23:02] <jai> heh [18:23:07] <jai> BBB: tak [18:23:25] * BBB goes look at wvp2 also [18:23:26] <kshishkov> jai: tak goes to Ukraine [18:23:29] <BBB> does anyone have that binary? [18:23:31] <jai> wasnt kshishkov working on aic [18:23:35] <kierank> dts-hd [18:23:48] <kshishkov> BBB: mplayerhq.hu does [18:23:53] <jai> kshishkov: excellent :) [18:23:57] <BBB> what's the name again? [18:23:58] <kshishkov> BBB: wmvadvdec.dll [18:24:01] <peloverde> mp3pro [18:24:31] <kshishkov> jai: in case you still didn't get it, I tend to use word "Ukraine" instead of certain swearwords [18:24:49] <jai> kshishkov: oh, i thought you meant you'll do it at some point :) [18:24:54] <astrange> if you RE tak he'll probably change the format in the next version [18:25:11] <kshishkov> I read discussion about opensourcing it at HA [18:25:11] <jai> astrange: same threat came from bink devs [18:25:19] <kshishkov> jai: no [18:25:27] <jai> but yeah, it would be a pita [18:25:37] <jai> kshishkov: so they have frozen the format? [18:25:42] <kshishkov> from RAR devs - yes, from Bink dev it was "go ahead" [18:26:12] <BBB> wmvadvd.dll for me [18:26:15] * BBB loads [18:26:18] <kshishkov> no, but it would be easy to update in case of something [18:26:19] <jai> kshishkov: hmm, didnt that guy say that they keep changing it with every release [18:26:43] <kshishkov> jai: who cares, most samples play well [18:26:57] <jai> kshishkov: sure [18:27:07] <kshishkov> and someone can add Bink version b for completeness sake [18:27:46] <peloverde> DonDiego: turns out nothing was screwed up about Major 06 kwestia 03, I was in my PS tree and it was bumping up against my incomplete PS code [18:28:13] <kshishkov> BBB: I have a bit of practice recognizing functions in binary WMV decoders [18:28:31] <kshishkov> BBB: if you don't know WVP2 may be described as "WMV3 with sprites" [18:29:05] <kshishkov> BBB: seems to be almost the same bitstream format with additional logic [18:30:05] <BBB> uhm... so it's an adaptation of wmv3? [18:30:18] <kshishkov> of course! [18:30:53] <BBB> yay [18:31:17] <kshishkov> ever wondered why that dll decodes WMV3, WMVA and WVP2 in a single package? [18:31:38] <BBB> really? [18:31:47] <kshishkov> yes [18:32:18] <BBB> omg I picked the biggest of the wm* dlls [18:32:23] * BBB bashes head against wall [18:32:25] <BBB> ohwell [18:32:36] <BBB> if it's an adaptation of wmv3 then it shouldn't be too bad [18:32:43] <kshishkov> no, look at MSS1/2 DMO decoder [18:33:09] <BBB> famous last words? [18:33:22] <kshishkov> it's also more than a megabyte - and it's decoder only [18:35:05] <kshishkov> unfortunately, all that IDA work resides on harddrive I can't read [18:35:15] <BBB> :-p [18:35:22] <kshishkov> (because there's no box with sata here) [18:35:37] <mru> get usb-sata cable [18:35:38] <BBB> I think I should simply start by wrapping the DLL in a ffmpeg wraper [18:35:58] <kshishkov> mru: I shall, when it's possible to walk outside [18:46:27] <kierank> any idea what SRCD could stand for? (Context: "subroutine error DD_SRCD_CONV returned %d" ) [18:46:47] <kshishkov> source code? [18:47:09] <kshishkov> or source data [18:47:56] <mru> or SR code, whatever that is [18:48:22] <kshishkov> or shift-right coded decimal :) [18:48:48] <astrange> sample rate conversion something [18:48:53] <mru> google offers some options [18:48:59] <mru> Society for Research in Child Development [18:49:09] <mru> Sydney RC Drifters [18:49:24] <mru> Scoil Rince Chill Dara [19:00:10] <astrange> oops, changed the patch and it won't finish recompiling before i have to go to class... a few minutes ago [19:00:13] <astrange> i'll send it later [19:00:44] <ramiro> astrange: I guess I'm not the only one who should have been in class a few minutes ago... [19:06:12] <bcoudurier> hi guys [19:06:39] <kshishkov> hi scripted greeting [19:10:52] <DonDiego> peloverde: please fill me in about latm support again [19:11:05] <DonDiego> i know i must have asked about a thousand times, sorry [19:11:24] <BBB> there's several issue tracker entries claiming sbr is broken btw? [19:11:32] <BBB> (recent ones, like "last few days") [19:21:29] <peloverde> DonDiego: the LATM has been in the same situation since Last april http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-April/068484.html [19:22:00] <peloverde> BBB: Across a variety of configure options I've been unable to reproduce the silent SBR issue [19:22:41] <peloverde> I've tried x86 32 and 64 bit builds with no asm, no yasm, and full asm, none trigger it for me [19:25:46] <nfl> bcoudurier: hi im interested in the seeking api gsoc task. is yop playback system a good enough small task for this? [19:33:15] <bcoudurier> IMHO latm should be added to the decoder [19:33:27] <bcoudurier> parsing could get quite complicated [19:33:35] <bcoudurier> peloverde, what do you think about that ? [19:33:47] <bcoudurier> nfl, not really IMHO [19:34:03] <peloverde> LATM isn't AAC specific [19:34:13] <kierank> it should be chained demuxing imo as with smpte-337m [19:35:00] <bcoudurier> well I'm not sure [19:35:11] <bcoudurier> s337m is trivial [19:35:29] <kierank> but there's still multiple streams that impersonate as one [19:35:33] <kierank> which is similar to latm [19:35:52] <bcoudurier> is it used in practice ? [19:36:05] <kierank> only with dolby e [19:36:16] <bcoudurier> that's because dolby-e is marked as pcm [19:36:23] <bcoudurier> used in passthough [19:37:03] <kierank> everything is effectively pcm with smpte-337m [19:37:05] <bcoudurier> through SDI link basically [19:37:18] <bcoudurier> then the dobly-e hardware decoder is plugged in [19:37:43] <bcoudurier> I believe LATM is only used with AAC in TS currently [19:38:04] <kierank> well yes but my point is that ts -> latm -> multistream aac is sort of like ts -> smpte-302m -> smpte-337m -> dolby e [19:38:12] <kierank> in that there are multiple demux stages [19:38:30] <bcoudurier> I have a feeling that probably chained decoders is easier that chained demuxers [19:39:29] <Dark_Shikari> we already do chained demuxers [19:39:41] <bcoudurier> like ? [19:39:54] <kshishkov> that's ball-and-chained demuxers [19:40:01] <kshishkov> dv-in-avi [19:40:08] <Dark_Shikari> dv in mov [19:40:08] <kshishkov> mpeg-in-mov? [19:40:14] <bcoudurier> that's the only case dv in something [19:40:27] <Dark_Shikari> if we ever supported it [19:40:29] <bcoudurier> and that is awfully hackish [19:40:29] <Dark_Shikari> vorbis in ogg in avi [19:40:33] <Dark_Shikari> ;) [19:40:48] <kshishkov> asf-in-mov ftw [19:41:48] <mru> I've heard of mpegts in mp4 [19:41:55] <kierank> i've heard of that too [19:41:56] <bcoudurier> mru, exact [19:42:03] <bcoudurier> there are specs also [19:42:11] <superdump> lol [19:42:12] <kshishkov> there is mpeg-ts/es in avi too [19:42:18] <peloverde> The truth is there are about a dozen ways to mux AAC into various containers and they shouldn't all be jammed into the AAC decoder, it's nutty, especially when many of them can be used with any MPEG-4 audio format [19:42:35] <peloverde> Just handling ADTS and ASC has already caused a huge mess [19:42:56] <superdump> the channel config stuff is fuuuuun [19:43:05] <superdump> especially when people don't do it right [19:43:12] <superdump> (files i mean) [19:43:13] <bcoudurier> well according to manufacturers APIs they all support LATM through the aac decoder [19:44:23] <bcoudurier> for dolby-e I'm sure it supports s302m as input and if its pcm, just copy the frames [19:44:51] <bcoudurier> like the wrle decoder handles both uncompressed and compressed [19:45:51] <bcoudurier> but peloverde if you feel it will be cleaner and simpler through a parser or demuxer, that's fine :) [19:48:51] <peloverde> It belongs in a demuxer, there are too many ways we generate illegal streams or refuse to do legal simple things with just ADTS and ASC as first class AAC formats, not to mention that it is a codec agnostic intermediate format [19:49:08] <peloverde> And it is used in the wild with things other than AAC [19:49:19] <peloverde> like BSAC in T-DMB [19:58:00] <mru> oi [19:58:08] <mru> oops [19:58:21] <mru> damn android softkbd [19:58:44] <peloverde> Is icl on windows a supported platform? [19:58:51] <mru> no [19:59:01] <mru> it emulates msvc [19:59:46] <peloverde> Then why are people complaining that the AAC decoder causes heap corruption using it? [20:00:41] <kshishkov> selfinflicted damage? [20:00:47] <jai> they use it at work perhaps [20:03:42] <peloverde> Oh well, that's one SBR "bug" dealt with [20:07:24] <mru> what are you saying? did someone manage to compile ffmpeg with icl? [20:08:46] <peloverde> see the AAC memory corruption thread [20:11:42] <peloverde> Dude was complaining about memory corruption, we asked for a GDB backtrace or valgrind log, says he doesn't use GNU tools, admits to using icl on windows [20:11:49] <mru> reading it now [20:37:13] <BBB> peloverde: did you run it under valgrind? just to make sure [20:37:28] <peloverde> BBB: yes I did run under valgrind [20:37:33] <BBB> ok [20:38:01] <peloverde> In fact I've run it extensively under valgrind. I've even fuzzed it under valgrind. [20:39:35] <BBB> that's pretty awesoe [20:40:10] <ramiro> pavel pavlov has a badly hacked up ffmpeg to build with icl [20:40:19] <ramiro> he started a couple of threads last year about it. [20:41:00] <peloverde> I believe some of the google people have expressed vague interest in ffmpeg+icl [20:41:53] <twnqx> expect more such reports with gcc 4.5 :P [20:45:44] <ramiro> http://gcc.gnu.org/ml/gcc/2010-03/msg00155.html [20:45:51] <ramiro> nice way to "fix" a bug. downgrade it to p2... [20:46:21] <peloverde> I was about to paste that [20:46:35] <DonDiego> icl? [20:46:39] <mru> hmm, archive reckons mr pavlov is mostly clueless [20:46:46] <mru> DonDiego: intel compiler for windows [20:46:55] <mru> msvc compiler is cl.exe [20:47:03] <DonDiego> ah, thx [20:47:41] <elenril> wtf [20:47:53] <elenril> all these uses of start_time in ffmpeg.c look horribly wrong [20:49:17] <elenril> anyone knows how it's supposed to work? [20:49:24] <mru> no [20:50:01] * elenril git blames [20:54:15] <elenril> hmm and apparrently it's been wrong since at least 2003 [20:55:08] <mru> that's plenty enough time for reality to adapt [20:58:09] <pJok> if it has been wrong for so long, it must be right ;) [20:59:18] <elenril> start_time is set to 0 after opt_input_file() [20:59:36] <elenril> but it's used in av_encode() and output_packet() [20:59:44] * elenril sighs [21:00:02] <elenril> and i just wanted to copy chapters, not uncover sceletons in ffmpeg's closet [21:00:31] <pJok> you should have knocked before you opened up [21:02:26] <bcoudurier> yes [21:02:51] <bcoudurier> start_time has different behaviour whether is before -i or after -i [21:03:10] <mru> self-modifying semantics [21:03:53] <elenril> as in it's not a bug, it's an undocumented feature? [21:05:20] <elenril> what does -ss mean for an output file then? [21:08:09] <mru> nothing I suppose [21:14:03] <elenril> well either it's been wrong for 7+ years or it has some hidden meaning [21:14:08] * elenril hopes it's the latter [21:15:07] <Kovensky> if it's the former it will make for some fun ML discussion [21:15:10] <Kovensky> fflames :D [21:16:05] * twnqx sets kovensky on fire [21:18:54] * Kovensky burns [21:20:54] * twnqx tries to extinguish the flames with some Cachasa [21:21:18] <Kovensky> cachaÃ§a* [21:21:59] <twnqx> i lack that key :X [21:22:15] <mru> copy&paste [21:22:22] <twnqx> Ã§ [21:22:24] <twnqx> Â¢ [21:22:25] <twnqx> Â© [21:22:27] <twnqx> hm [21:23:11] <twnqx> áºÃ [21:23:20] <twnqx> weird, two of those... [21:29:35] <J_Darnley> Um... I can tell you what -ss does for an output file. [21:30:32] <elenril> so? [21:31:34] <J_Darnley> It appears to tell the encoder to wait TIME before encoding the first frame [21:34:00] <elenril> hmmm, yeah, it seems you're right [21:34:21] * elenril headdesks [21:34:26] <elenril> why does it have to be so complicated [21:35:08] <J_Darnley> People have complained in the past that using -ss "makes ffmpeg slow" [21:35:21] <J_Darnley> but that is because it was after -i [21:40:53] <elenril> i hope -t doesn't have any hidden meanings [21:47:53] * elenril wondes how do -ss'es before and after -i combine [21:53:58] <J_Darnley> Add probably

1 0

IRC log for 2010-03-16
by irc＠mansr.com 17 Mar '10

17 Mar '10

[00:00:21] <Dark_Shikari> hmm. what's the best way to sum up the size of .o files in a folder? [00:00:24] <Dark_Shikari> i.e. "du", but only for .o files [00:00:36] <janneg> du -s *.o [00:00:36] <mika_video> So here we do have a case where the ABI comptibility has been broken but the MAJOR version number has stayed the same. [00:00:43] <Dark_Shikari> it's -c [00:00:54] <Dark_Shikari> du -b -c folder/*.o | tail --lines=1 [00:01:13] <mru> mika_video: which commit? [00:01:34] <mika_video> mru: I do not undetstand your comment "mru> mika_video: which commit?" [00:01:43] <Yuvi> mika_video: um, git blame shows the only change in fields before codec_type were const changes and void* -> uint8_t* [00:01:50] * mru gives up [00:01:51] <Yuvi> since ~2002 [00:02:51] <Yuvi> and nothing since 2008, when the major version was bumped [00:02:58] <mika_video> I was trying to find out why the delho demo program does not work. The delphi header were downloaded from page: http://www.iversenit.dk/dev/ffmpeg-headers/ [00:04:50] <mika_video> <mru>: is it somehow hard to translate these 52.0.0 and 52.55.0 versin numbers of libavcodec to some revision numbers you seem to want to know ? [00:07:01] <peloverde> mika_video, http://git.ffmpeg.org/?p=ffmpeg;a=history;f=libavcodec/avcodec.h;h=43a06955… [00:08:34] <Yuvi> oh I'm slightly wrong, r4168 went from int -> AVRational, still well before major version 52 though [00:10:21] <Yuvi> mika_video: svn blame libavcodec/avcodec.h will show you when LIBAVCODEC_VERSION_MAJOR, _MINOR, and _MICRO were bumped [00:12:46] <mika_video> here you can see the 52.0.0 I was refering to: http://git.ffmpeg.org/?p=ffmpeg;a=blobdiff;f=libavcodec/avcodec.h;h=43a0695… [00:15:58] <mika_video> is there a way to download, say version 52.0.0 of avcodec.h ? [00:16:38] <peloverde> the "raw" link on gitweb [00:17:08] <mika_video> <peloverde>: any URL wow to get that ? [00:19:19] <Yuvi> the only potential abi breaks I see are avcodec_find_best_pix_fmt, subtitle stuff, SAMPLE_FMT_S24, and error_resilience -> error_recognition [00:19:36] <mru> renaming doesn't break abi [00:19:41] <Yuvi> or that last one is api not abi [00:21:06] <mika_video> <Yuvi>: then how can you expkain this: In avcodec version 52.0.0 the codex_type field of struct AVCodecContext was at offset 0xE0 but in version 52.55.0 it is located at offset 0xdc ? [00:21:10] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=blob_plain;f=libavcodec/avcodec.h;h=05f79… [00:21:25] <Yuvi> mika_video: you're doing something wrong [00:21:41] <mru> like talking about a field that doesn't exist :-) [00:21:54] <mika_video> And I do not know how to make those version numbers into revision numbers since I can see here that many of you here like to refer to revision numbers instead. [00:22:29] <mru> mika_video: how do you know the offset is different? do you have both versions of the file? if so, please pastebin a diff [00:23:32] <Yuvi> and all of that (except the subtitle stuff) happened soon enough after the 52 bump that it should be part of the 52 abi [00:23:40] <mika_video> <Yuvi>: I was wondering why a program written in Dephi does not work. So I wrote a small test program in C to print offsets to all structure members and compared that with the same information from the delphi program and found out that the codex_type field has moved [00:23:50] <janneg> git annotate --reverse only lists fields under LIBAVCODEC_VERSION_MAJOR < 52 as removed [00:24:29] <janneg> mika_video: there is no field codex_type. do you mean codec_type [00:25:43] <mika_video> mru: I have a C-language version of the 52.55.0 But I have a delphi version of 52.0.0. Unfortunately it makes no sense to fiff between a C language .h file and a delphi .pas file [00:26:27] <mru> maybe the .pas is broken [00:26:30] <janneg> so you use different compilers to compile completly different files [00:26:30] <mika_video> mru: so to make such diff'ing meaningful I would need to download the C-language .h version of 52.0.0 - but I do not know how to do that [00:26:37] <Dark_Shikari> mru: not "maybe" [00:26:38] <Dark_Shikari> it _is_ [00:26:55] <mru> we don't know which version of the .h is was made from, so we can't say for sure [00:27:31] <mru> but c and pascal probably use different field packing rules [00:27:45] <mru> a naive translation would probably not work so well [00:28:00] <mika_video> the .pas file has this: LIBAVCODEC_VERSION_MAJOR = 52; LIBAVCODEC_VERSION_MINOR = 0; LIBAVCODEC_VERSION_MICRO = 0; [00:28:12] <mru> we got that [00:28:24] <mru> doesn't mean much [00:29:12] <mika_video> that translation is not done by me. I will next write a tool that prints offsets of both the C -language .h version and the .pas version used by delphi and tells whether there are any differences and lists them if there is [00:29:13] <janneg> http://git.ffmpeg.org/?p=ffmpeg;a=tree;h=be7f65a11136664312b8b765034c757a5c… [00:29:37] <mru> so you _do_ have the C file for both revisions?? [00:29:50] <mika_video> <janneg>: yes, codec_type is what I mean [00:30:03] <Dark_Shikari> mru: he doesn't understand what "independent variable" means [00:30:07] <Dark_Shikari> or "control" [00:30:14] <mru> or "version" [00:30:17] <mru> or "file" [00:30:20] <mru> or "pascal sucks" [00:30:22] <mika_video> <mru>: NO. I have the C version of only 52.55.0 [00:30:51] <janneg> mika_video: http://git.ffmpeg.org/?p=ffmpeg;a=blob_plain;f=libavcodec/avcodec.h;hb=0472… [00:31:05] <Dark_Shikari> mru: http://www.actsofgord.com/Annoy/chapter03.php first entry [00:31:44] <mru> lol [00:31:56] <Dark_Shikari> (that entire site is an absolute hoot, but that's the most relevant one) [00:32:38] <mika_video> <mru>: That "pascal sucks" is a common misunderstandiong of C programmers, and it is correct if you think about some very outdated version of pascal that was standardized by ISO orgainzation in 1970 or something. Nowadays it's object pascal (the difference being more than between C and C++) and the hardest part of writing a vido app in Delphi is to get the ap and the C library to correctly understand each other [00:33:10] <Dark_Shikari> "object pascal" sounds worse than pascal [00:33:16] <mru> but, but... why is the lib in C if pascal is so great? [00:33:19] * mru is puzzled [00:33:30] <Dark_Shikari> I mean, I find this argument funny [00:33:41] <mika_video> <mru>: ask yourself: why did you write it in C ? [00:33:51] <Dark_Shikari> "C programmers think pascal is crap because it's outdated, but just like C was updated to C++, pascal was updated with object pascal!" [00:34:01] <ramiro> oh, come on. let's not start this... [00:34:02] <Dark_Shikari> But wait. If they're C programmers, that means they don't like C++, or otherwise they would be using C++. [00:34:07] <ramiro> it's annoying noise [00:34:25] <Dark_Shikari> ramiro: I agree, let's take advantage of the intellectual osmosis argument. [00:34:53] <mru> ramiro: come on, can't we have a little bit of fun? [00:45:51] <mika_video> the diff between avcodec.h versions 52.0.0 and 52.58.0 is here: http://pastebin.com/zPXEZ1pb [00:46:08] <mru> that's not what I requested [00:46:38] <mru> I asked for the diff between the files you claim give different offsets [00:46:41] <mika_video> <mru>: what then ? [00:52:07] <mika_video> mru: I believe that if you compile two C programs, one using 52.0.0 and the other using, say, 52.58.0, the two programs will see the same fieldname at different offsets. If I am wrong here, then someone made a bad mistake ttranslating that .h to delphi. And if they tested their delphi app ata all, such mistake would make itself known immediately [00:52:50] <mru> well, try it [00:53:26] <mru> Catastrophic error: could not set locale "" to allow processing of multibyte characters [00:53:29] <mru> lol [00:53:43] <mika_video> Well, to create an app in C that only needs avcodec.h but does not actually do anything with video data, what else do I need to #include or link, or is avcodec.h alone enough ? [00:54:01] <mru> didn't you say you had such an offset-printing app already? [00:54:27] <ramiro> mika_video: this is outside the scope of this channel. try asking on the libav-user mailinglist. [00:56:30] <mika_video> mru: so far the process is quite long. 1. I use an external app to convert .h to .xml ... then I have a delphi app to read that xml and produce an iclude file for a C program, and then I can use gcc to compile a skeleton C app that has #include showfields.inc (the app uses some C macros to print out offsets and sizes with every field name listed in showfields.inc) [00:57:12] <Dark_Shikari> lol [00:57:23] <mika_video> <ramiro>: would it be considered on-topic after proving that there was a change wich breaks ABI but MAJOR version number stayed the same ? [00:57:34] <Dark_Shikari> sure, if you do so with a C compiler [00:57:37] <Dark_Shikari> with the C language [00:57:39] <Dark_Shikari> including a C header [00:57:43] <mru> we're waiting for that proof... [00:58:22] <mika_video> Well, can pastebin accept .zip files (a nice way to package .c and .c files etc. [00:58:39] <ramiro> what would you want to put there? [01:00:14] <mika_video> <ramiro>: a main program file in .c then two versions of avcodec.h, at least one renamed and also the struct name renamed, an include file that when #included in the C main program, will cause the C app to print a list of fields and their offsets. [01:00:51] <mika_video> Or, if the two versions of the C app are compiled separately, tthen the renaming is not needed [01:07:07] <bcoudurier> hi guys [01:07:14] <Dark_Shikari> hi bcoudurier's autojoin script [01:07:26] <mru> yay, the script is back [01:07:31] <bcoudurier> nope [01:08:58] <mika_video> so: what are the minimum requrements to create a working C program where I #include "avcodec.h". What else I absolutely must #include too to make it work ? [01:09:57] <Yuvi> mika_video: http://www.pastie.org/871392 [01:10:27] <bcoudurier> it seems gmaxwell find the ogg muxer code horrible, does anyone know what's so horrible about it ? I just asked him as well [01:10:46] <Yuvi> bcoudurier: it has 10-20% overhead for vorbis [01:11:43] <Yuvi> bcoudurier: I did http://www.pastie.org/871394 to fix that, but it needs to interleave pages based on start time not granule [01:11:47] <mru> it's an ogg muxer, of course it's horrible [01:12:13] <Yuvi> (not rebased on today's fix yet) [01:13:11] <Dark_Shikari> Yuvi: did you get gmaxwell's message? [01:13:28] <Yuvi> yeah, bcoudurier applied the fix before I really looked at it [01:13:40] <bcoudurier> yeah, there was an odd case [01:13:58] <bcoudurier> so it does pack multiple packets in one page ? [01:14:11] <Yuvi> for audio only [01:14:21] <bcoudurier> btw Yuvi I have problem decoding theora here [01:14:34] <bcoudurier> picture is garbage with latest svn [01:14:57] <mika_video> showoffs.c:8: error: AVCodecContext has no member named codec_type [01:15:02] <bcoudurier> [theora @ 0x2499350]error in unpack_block_qpis [01:15:06] <bcoudurier> vlc plays fine though [01:15:24] <bcoudurier> Yuvi, that needs a parser [01:16:57] <Yuvi> bcoudurier: link to file? mine work [01:17:26] <Yuvi> and how would a parser help in the muxing case? the muxer still needs to know the individual packet sizes and pack them together itself [01:17:50] <bcoudurier> decoding [01:18:05] <CIA-92> ffmpeg: mru * r22565 /trunk/ (13 files in 5 dirs): [01:18:05] <CIA-92> ffmpeg: Move H264 dsputil functions into their own struct [01:18:05] <CIA-92> ffmpeg: This moves the H264-specific functions from DSPContext to the new [01:18:05] <CIA-92> ffmpeg: H264DSPContext. The code is made conditional on CONFIG_H264DSP [01:18:05] <CIA-92> ffmpeg: which is set by the codecs requiring it. [01:18:06] <CIA-92> ffmpeg: The qpel and chroma MC functions are not moved as these are used by [01:18:07] <CIA-92> ffmpeg: non-h264 code. [01:19:07] <Dark_Shikari> mru: btw, the last entry on http://www.actsofgord.com/Annoy/chapter13.php is very very useful as well [01:19:11] <Dark_Shikari> the "retarded monkey" approach [01:19:26] <Dark_Shikari> "that ffmpeg looks like it was configured by a retarded monkey" [01:19:31] <Dark_Shikari> "what, I didn't--" [01:19:36] <Dark_Shikari> "I didn't blame you, I blamed a retarded monkey." [01:19:48] <Yuvi> bcoudurier: sorry, I don't understand where the parser is coming in [01:24:33] <mika_video> showoffs.c:3:32: error: libavcodec/avcodec.h:file not found. What??? - can gcc not understand symbolic links on linux ? (I just did ln -s libavcodec.h versions/avcodec_52_58_00.h, after renaming the original) [01:24:59] <ohsix> heh [01:25:32] <mru> maybe you're the one not understanding symlinks [01:26:58] <bcoudurier> Yuvi, it seems the parsing will be done according to the lacing values [01:28:00] <Yuvi> that happens in the ogg demuxer, it recombines the packets as written [01:28:56] <bcoudurier> yes [01:29:00] <mika_video> cannot get that example program compiled. using that #include <libavcodec/avcodec.h> the gcc cannot find even avcodec.h. And if I change that to #include "libavcodec/avcodec.h" then gcc can find avcodec.h but hen it complains libavcodec/avcodec.h:30:30: error: libavutil/avutil.h - file not found [01:29:37] <ohsix> how do i shot web [01:29:50] <mika_video> I thibnk it needs some compiler switch to make gcc search the correct path for int's #include's [01:29:56] <Yuvi> it's actually impossible to parse a raw theora stream into packets, I think it is for vorbis as well [01:32:16] <mika_video> <Yuvi>: how to get your example to compile. Is it possible even without a makefile ? [01:33:05] <Yuvi> mika_video: http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html add -I<path> [01:33:29] <mika_video> I am now trying to compile on linux. But my own test program was compiled on windows using the mingw-gcc and the only way to get it compile ok, was to spy on what commend line the gnu make gives to gcc, and then copy and modify that to get my own C app compiled [01:36:00] <mika_video> Yuvi: I tried gcc -I./ -I./libavutil/ -o showoffs showoffs.c - taht removes most of the error messages, but it still complains this: ./libavutil/pixfmt.h:32:32: error: libavutil/avconfig.h: file not found [01:36:29] <Dark_Shikari> ohsix: Â¯\(Âº_o)/Â¯ [01:38:11] <mika_video> how do I order make to not actually do anything but instead output all the command it *would* do if invoked normally ? [01:40:31] <Yuvi> bcoudurier: also, another bug (I think): eos is written on multiple pages if the packet spans more than one [01:40:53] <Yuvi> or no, the current code is fine, it's my code that does that [01:41:40] <bcoudurier> ah ok [01:41:56] <ramiro> bcoudurier: hi [01:42:07] <bcoudurier> hi ramiro [02:09:21] <mika_video> It seems you guys here are right and whoever made that .h to .pas conversion, made a mistake. I am surpised of that, because if that guy had test his program, such a mistake would show up immediately ! [02:10:00] <mika_video> Well, I am just surprised that some people just post code on the net and do not even test their apps to run correctly ! [02:59:53] <ramiro> mika_video: that's pretty common... [03:00:55] <ramiro> mru: if you want more examples of sucky pkg-config usage, try liborc + schroedinger 1.0.9 [03:01:22] <ramiro> mru: and even more fun from freedesktop.org: http://www.mail-archive.com/schrodinger-devel@lists.sourceforge.net/msg0029… [03:01:35] <ramiro> "lost the home directory [03:01:43] <ramiro> in a power outage" [03:01:45] <ramiro> incredible... [03:03:33] <astrange> with git you don't have to bother with redundant storage [03:04:07] <ramiro> that doesn't make it ok to loose an open-source project because of a power outage =) [03:04:48] <Dark_Shikari> "lose data in a power outage" [03:04:48] <Dark_Shikari> lol [03:05:06] <ramiro> orc has a library and a compiler. but - as is usual from freedesktop - they forgot that people might want to cross-compile [03:06:06] <ramiro> so libschroedinger uses the compiler and the library, I can run orcc.exe with wine, but not the w64 version... [03:25:39] <mru> they clearly don't care [03:45:07] <ramiro> liborc is great. it's not designed for static libraries *and* for cross-compilation! [03:45:34] <ramiro> much like liboil. I opened a bug because it didn't build with --disable-shared --enable-static and it was WONTFIXed... [03:53:24] <mru> like anything from the fdo vicinity [03:56:24] <mru> liboil always makes me think of snake oil [04:13:01] <ramiro> notabug http://bugs.freedesktop.org/show_bug.cgi?id=27103 [05:55:00] <pJok> mornings [06:39:57] <pJok> god morgon, kshishkov :) [06:54:39] <kshishkov> god morgon, pJok [06:55:10] <thresh> moroning, Kostya [06:56:23] <kshishkov> told you, it's idioting here [06:57:44] <thresh> whatever floats your boat :) [06:58:40] <kshishkov> whatever floats and it's not cream [07:08:52] <KotH> en wunderschöne guete morge! [07:11:56] <av500> guten morgen [07:12:20] <kshishkov> any reasons to think so? [07:13:47] <kshishkov> for example, "I've managed to render 40 frames for BBB this morning on machine with 3G RAM. All of them were black though" [07:13:49] <pJok> sun is shining, its not bitterly cold or blistering hot outside [07:14:00] <pJok> i almost slept a full night [07:14:08] <pJok> thats almost a good morning for me [07:14:26] <kshishkov> accepted [07:15:25] <av500> guten morgen (try2, kshishkov excluded) [07:16:09] <kshishkov> av500, you forgot to add "I say so on my own free will and without any duress" [07:17:09] <av500> I can run it thru /tools/good_morning_check maybe? [07:19:08] <pJok> and i got a seat on the train... thats more than to be said for the people who are next to me :D [07:19:59] <kshishkov> pJok: at least it's not that lucky occasion as here [07:20:54] <pJok> well, i get on on the station before the next biggest and two stations before the biggest exchange of passengers [07:21:24] <pJok> so i usually get a seat at least at the next biggest exchange if i didn't get one at the station i got on [07:21:30] <kshishkov> MalmÃ¶ kg Kobenhavn? [07:22:02] <pJok> lund and malmö [07:22:19] <pJok> train stops at helsingborg, landskrona, lund and malmö [07:22:53] * av500 will be in Kobenhav in June it seems [07:22:56] * kshishkov once went from GÃ¶teborg to Copenhagen by ÃresundstÃ¥g [07:26:08] <pJok> same route as i take every morning [07:29:57] <KotH> kshishkov: i think you should start with meditations or something [07:30:18] <KotH> kshishkov: because it's a wonderfull morning, you just dont want to see it ;-> [07:30:48] <kshishkov> KotH: it's a bit spoiled by Ukraine around me [07:31:13] <kshishkov> try living here for a week for starters [07:31:25] <twnqx> i almost did that for ~2mnoth [07:31:27] <twnqx> :S [07:31:38] <twnqx> but then i refused that resident engineer position [07:32:20] <kshishkov> just in case, Kiev != Ukraine [07:32:34] <twnqx> so kiev would have been acceptable? [07:33:42] <kshishkov> compared to other places here - yes [07:33:54] <kshishkov> many people try to live there [07:35:17] <KotH> then why dont you move to kiev? [07:35:55] <KotH> there you could live a happy life until we get the rescue team formed and equipped [07:36:34] <kshishkov> KotH: it's hard [07:37:14] <kshishkov> not to mention that real estate prices there are higher than in Europe [07:37:42] * KotH doesnt believe that [07:37:47] <KotH> unless you dont count zürich to be in europe [07:38:07] <av500> http://www.economist.com/research/articlesBySubject/displaystory.cfm?subjec… [07:38:18] <av500> about expensive cities [07:39:38] <av500> we actually thought about setting up a team in kiev. laber was cheap, but all the other stuff around that made it a nogo in the end [07:39:43] <kshishkov> food is rather cheap here, some other things too [07:41:18] <KotH> av500: i dont think that tokyo is that expensive [07:41:52] <KotH> av500: when i did my internship there, tokyo was cheaper than zürich, which in turn is a lot cheaper than london, for example [07:42:11] <kshishkov> hmm, a year ago Kiev was on 46-th place in global cost of real estate rating [07:42:24] <thresh> suppose now it's waaay higher [07:42:38] <av500> kshishkov: could have been the expensive mafia bribes in the end :) [07:43:32] <kshishkov> http://www.globalpropertyguide.com/Europe/rent/ [07:43:40] <kshishkov> 7th place, yay! [07:44:58] <av500> but u still dont beat paris! [07:44:58] <kshishkov> but if you compare hotel prices Copenhagen may get 0th place [07:48:43] <KotH> kshishkov: .ch is at 4th place...so stop complaining! [07:49:59] <kshishkov> KotH: an average income here is < 200 Eur/month (300 for Kiev though) [07:50:10] <thresh> duh, we're third [07:50:25] <thresh> wait what, 4k euro per month? wtf? [07:50:25] <kshishkov> and I don't complain - it's the thing you have to be proud about [07:51:56] <pross-au> 4k euro a month! [07:51:58] <pross-au> FFS [07:52:52] <thresh> well that price is probably valid if you live near Kremlin [07:53:22] <kshishkov> look at square meter prices [07:53:52] <andoma> sweden is not even in there [07:54:19] <thresh> kshishkov: yeah, the price is normal for Moscow centre [07:55:24] <kshishkov> thresh: yes since you have Khanty-Mansiysk to cover those prices [07:55:51] <thresh> yeah, though living in moscow centre is kind of stupid [07:56:01] <kshishkov> tell that to Putin [07:56:20] <thresh> he lives in Barviha [07:56:52] <pross-au> paying about ~800 eu/month here [07:57:52] <kshishkov> thresh: I thought it was Yeltsin's residence and your current Prime Minister lives in St.Putinsburg [08:00:08] <kshishkov> pross-au: any codecs you'd like to have REd? [08:00:24] <pross-au> MicroTalk [08:00:42] <pross-au> Toilet also needs cleaning kshishkov [08:00:55] <kshishkov> from spiders? [08:01:01] <pross-au> them too! [09:22:26] <hyc> wbs: fyi, librtmp publish/RTMP_Write is working now [09:22:40] <wbs> hyc: great :-) [09:23:02] <kshishkov> *now* who's copying stuff ;-) [09:23:11] <wbs> that's at least one showstopper less for integrating it for my part [09:23:18] <hyc> lol [09:26:14] <hyc> kshishkov: I'm ashamed to admit, I couldn't even copy your routine, due to other bugs in my code [09:26:35] <hyc> my SendPacket was spitting out wrong timestamps... [09:26:51] <kshishkov> it's not mine though [09:28:27] <hyc> no? anyway I would never have seen the problem if it weren't for wbs asking about RTMP_Write [09:29:00] <kshishkov> it was some other guy who wanted to have publishing, I just assisted getting it to SVN [09:30:16] <hyc> ahh. well, now it's in 2 SVNs. :P [09:30:38] <kshishkov> fine with me [09:31:20] <kshishkov> and I suspect we got C version of RTMP client earlier than you :P [09:32:31] <hyc> heh heh. looks like it. [09:33:05] <hyc> well, that was before I had any choice in the matter.... [09:33:48] <hyc> C++ < C ;) [09:34:16] <kshishkov> depends on how compiler does it ;) [09:34:42] <hyc> the original version of this code was awful, using that Boost crap [09:34:55] <hyc> it's like nobody knows how to write a single honest line of code these days [09:35:19] <hyc> they all need to instantiate this or that stupid class / template / whatever [09:35:29] * kshishkov turned from C++ in times when STL began to be remotely consistent between compilers [09:36:00] <wbs> I use C++ for my own applications, but really prefer C for libraries [09:36:27] <hyc> I find that C++ just obfuscates [09:36:52] <hyc> but whatever, yeah, certainly for low level code, there's no benefit from C++ [09:37:14] <kshishkov> from my experience Java now is also mostly a cartload of commons-* libs to do some simple task [09:39:11] <kshishkov> Boost is used to minimize the difference between C++ and Java [09:39:45] <hyc> no wonder I didn't like it. ;) [09:40:14] <kshishkov> maybe you are a programmer and not a code monkey [09:40:42] <hyc> is code monkey just a step up from script kiddie? [09:40:51] <kshishkov> ook [09:42:05] <pJok> afternoon jai :) [09:42:21] <jai> good afternoon pJok :) [09:43:18] <kshishkov> jai: it's too early for that there [09:43:43] <jai> kshishkov: well, it is afternoon here :) [09:43:56] <kshishkov> so I gather [09:44:29] <jai> ooh, filter for changing the aspect ratio [09:44:32] <kshishkov> I wonder if you also have the same word for morning and evening [09:45:12] <jai> kshishkov: different words for all phases of the day [09:45:19] <kshishkov> godd [09:45:21] <kshishkov> *good [09:46:46] <hyc> for what it's worth, testing against rtmplite isn't always so great either [09:46:56] <hyc> http://code.google.com/p/rtmplite/issues/detail?id=1#c0 [09:47:29] <hyc> the maintainer doesn't seem to pay attention or actually do any maintaining... [09:47:43] <kshishkov> "worksforme" [09:48:05] <kshishkov> in terms "it does all _I_ need, no need to bother about somebody else" [09:48:53] <hyc> the other reason it took me so long to get the publish timestamps right is that rtmplite was recording them incorrectly [09:49:08] <hyc> I guess I could post another issue there, but seems futile [09:49:29] <kshishkov> why not get something else? [09:49:34] <kshishkov> Red5 for example? [09:49:49] <hyc> too big. don't want to spend the time figuring out how to configure it [09:49:53] * kshishkov used mostly some simple RTMP servers in Ruby and Perl [09:51:34] <hyc> from where? [09:52:25] <kshishkov> rubyizumi or something from googlecode [09:52:38] <kshishkov> and random RTMP links [09:53:44] <hyc> yeah, I've done plenty of those. seems like there's never one just when you want it though. [09:55:17] <hyc> it's gotten easier lately, stream-recorder.com forum usually has a lot of URLs to try [09:59:35] <merbzt> janneg: the torrent doesn't work [09:59:52] <merbzt> got the box working with 4gb of memory now [10:00:13] <merbzt> so it should be able to do somework [10:03:27] <superdump> i should get my i7 churning [10:03:31] <superdump> it's not doing anything [10:03:44] <superdump> what do i need to do? and what are we rendering? [10:03:51] * kshishkov has idle BeagleBoard [10:04:40] <hyc> kshishkov: any plans for it? I have two AI TouchBooks here [10:04:57] <hyc> they're actually the reason I started hacking on rtmpdump... [10:06:13] <twnqx> anyone fit with git here? i reverted a patch and got a new git revision... how do i kill all traces of that and go back to before reverting? [10:06:28] <wbs> twnqx: reset <hash> [10:06:42] <wbs> and you probably want --hard if you don't want to keep the changed files in the work area [10:06:43] <av500> hyc: send one to me of course :) [10:06:49] <twnqx> thanks [10:07:29] <hyc> av500: heh, I thought you already had something [10:07:48] <merbzt> twnqx: "git check sheet" is an ok short reference [10:07:55] <av500> of course I have "something", but dont we always want more? :) [10:08:11] <hyc> lol. Yes! which is why I'm keeping both of mine. ;) [10:26:05] <superdump> merbzt , janneg : what are we rendering and what's needed to do it? [10:33:29] <merbzt> superdump: BBB in 2*HD I think [10:33:45] <superdump> any good reason? [10:33:56] <merbzt> for the screen wall [10:34:26] <superdump> mmm [10:34:32] <superdump> well, where are the instructions? [10:35:50] <merbzt> http://jannau.net/bbb_videowall/ [10:37:49] <superdump> does janne have somewhere to which i can upload the images once they're done [10:37:59] <superdump> i won't have enough webspace anywhere [10:38:12] <merbzt> I think so [10:38:18] <superdump> ok [10:38:28] <superdump> i'll get it going in a minute then [10:38:46] <merbzt> I don't get the torrent working ;/ [10:41:51] <superdump> maybe the tracker is down [10:42:49] <superdump> working for me now [10:43:14] <superdump> have you set up port forwarding/upnp for your torrent client? [10:48:03] <merbzt> nope [10:50:09] <merbzt> guess it's blocked [11:49:21] <mru> av500: is your arm/h264 build issue fixed? [12:01:32] <mcgeagh> hello all. Im wondering if any work is going on, or planned to, for incorporating OpenMAX into ffmpeg??? [12:01:42] <mru> no [12:01:54] <av500> mru: I did not retest yet [12:02:15] <av500> I package a svn snapshot, so I'd need to repeat that [12:02:39] <mru> just shout if it's still broken next time you try it [12:02:43] <av500> yup [12:02:48] <av500> shout I will :) [12:02:56] <mru> no doubt [12:03:31] <mcgeagh> mru, has there been any discussion about ever incorporating it in the forseeable future? [12:03:58] <mru> that's not likely [12:04:06] <mru> that it'll happen [12:04:19] <mru> openmax is a pile 'o stink [12:04:22] <thresh> even if someone sends a patch? [12:04:27] <mru> even then [12:04:45] <jai> does anyone have h/w with support? [12:04:47] <mcgeagh> oh, is it that bad? [12:04:59] <thresh> jai: many people have n900 ;-) [12:05:01] <mru> the API, if you can call it that, is a mess [12:05:31] <mru> when I looked at it, it wasn't even obvious _what_ the api was [12:05:34] <bilboed-tp> you want to stay away from openmax... really [12:05:40] <jai> thresh: hmm,k [12:05:46] <mru> and the ARM code I looked at was totally unreadable [12:05:48] <av500> bilboed-tp: come on, just another sandal, no? :) [12:06:35] <av500> or was it a shoe? [12:06:44] <bilboed-tp> it's seriously bad [12:06:45] <mru> both, and a boot outside of that [12:07:00] <bilboed-tp> it's just a collection of .h [12:07:03] <mcgeagh> ok, so if i do it (regardless if its a good idea or not) your not interested in it [12:07:06] <thresh> well, there is some support in VLC nowadays for that [12:07:06] <bilboed-tp> no reference implementation [12:07:23] <mcgeagh> i know gstreamer supports it [12:07:30] <av500> and gg made that the default for android /sigh.... [12:07:41] <mru> gst likes a mess [12:07:55] <mcgeagh> k, so no pollutants in ffmpeg [12:08:01] <mcgeagh> got it [12:08:05] <bilboed-tp> mcgeagh, there's a gstreamer plugin that attempts to support it ... yes [12:08:11] <av500> mcgeagh: why are you interested in it? [12:08:33] <mru> he's been misled to believe it would be useful, of course [12:08:42] <mcgeagh> yep [12:08:50] <mru> mcgeagh: are you talking about omx IL or DL btw? [12:08:53] <mru> or AL? [12:08:54] <mcgeagh> that and, i have hardware that supports it [12:09:01] <mru> and which version? [12:09:03] <kshishkov> mru: next thing you'll hear about IPP H.264 decoder again [12:09:05] <av500> mcgeagh: hw? [12:09:09] <mcgeagh> so instead of getting codecs specific for the platform, wanted to get ffmpeg to support it too [12:09:15] <av500> ??? [12:09:16] <mcgeagh> IL [12:09:21] <mru> kshishkov: ipp does have fast mpeg2 idct [12:09:38] <mcgeagh> i cant say on hw [12:09:43] <av500> mcgeagh: what hw? [12:09:52] <mcgeagh> and im assuming 1.1 version, but will check [12:10:09] <mru> the goal of ffmpeg isn't to be a wrapper for other libs [12:10:14] <mru> there's gst for that :-) [12:10:16] <mcgeagh> the hw isnt released yet so cannot talk about the hw [12:10:22] <av500> cpu? [12:10:29] <mcgeagh> arm [12:10:33] <av500> orly... [12:10:37] <thresh> :-) [12:10:45] <av500> not leg? [12:11:09] <av500> mcgeagh: and you have openmax codecs, or you want to write some? [12:11:31] <kshishkov> av500: that's why some of us call it not mere CPU but whole Acorn RISC Machine :P [12:13:32] <av500> mcgeagh: of course you could write a wrapper that would make openmax codecs callable via lavc API [12:14:07] <av500> but unless you plan to use ffplay a lot, this wrapper could also be outside... [12:14:31] <av500> i.e. in your multimedia app [12:46:47] <KotH> Subject: Re: [gst-devel] How can I have two main loops in my program?? [12:46:57] <KotH> (no comment) [12:47:13] <kshishkov> cheapskate [12:48:31] <av500> KotH: actually, we have that :) [12:49:05] <bilboed-tp> KotH, that guy is made of fail [12:50:59] <KotH> bilboed-tp: i've not read the discussion, just saw that subject scrolling by in my procmail.log [12:51:18] <bilboed-tp> KotH, the subject sums it up indeed :) [12:51:19] <KotH> av500: er.. you're a comercial company... i expect worse of you [12:51:33] <kshishkov> I suspect he'll ask for _nested_ loops next [12:52:42] <av500> KotH: actually, it was a nested mainloop construct that in the end we never used :) [12:52:54] <av500> nested ftw! [12:56:21] * kshishkov wonders if somebody's told him to add another label and jump instruction [15:49:46] <CIA-92> ffmpeg: rbultje * r22566 /trunk/ffmpeg.c: [15:49:46] <CIA-92> ffmpeg: Typo: if output (video) stream's pix_fmt is not set, then the stream cannot [15:49:46] <CIA-92> ffmpeg: be ENcoded, not DEcoded. [17:03:22] <superdump> peloverde: ping? [17:03:56] <kshishkov> you'd better use piNGGG with higher frequencies coded with SBR [17:04:46] <kshishkov> or PS (ping stereo) [17:20:15] <peloverde> superdump, pong [17:42:01] <peloverde> IE 9 announced H.264+AAC support, nice! [17:42:40] <BBB> wooh [17:42:43] <BBB> what other formats? [17:42:46] <BBB> WMV, I suppose? [17:43:26] <peloverde> I don't see anything about WM{A,V} but it wouldn't surprise me [17:43:52] <Dark_Shikari> wait, with HTML5 video? [17:44:24] <peloverde> yes [17:44:27] <Dark_Shikari> lol [17:44:31] <Dark_Shikari> oh god the drama will be funny =p [17:44:38] <thresh> yeah mozilla is fucked [17:44:42] <Dark_Shikari> Yeah [17:44:45] <Dark_Shikari> I saw this coming a mile away [17:44:46] <jai> more like butthurt [17:44:47] <mru> \o/ [17:44:49] <Dark_Shikari> I kept telling people this [17:44:53] <thresh> well everyone did i suppose [17:44:56] <Dark_Shikari> IE9 is going to support H.264/AAC [17:44:57] <Dark_Shikari> ... and it did [17:45:09] <Dark_Shikari> when it's going to come out? [17:45:23] <twnqx> how DARE they support non-free codecs [17:45:32] <mru> microsoft have realised that no matter how hard they push vc1, h264 is the de facto standard [17:45:41] <Dark_Shikari> mru: they realized that 3-4 years ago imo [17:45:48] <mru> yes [17:45:49] <Dark_Shikari> they've written their own h264 encoder since, and it's pretty good [17:45:54] <Dark_Shikari> and silverlight now does h264 standard [17:46:05] <mru> exactly [17:46:16] <peloverde> Dark_Shikari, their encoder seems like crap, it's limited to 4GB memory [17:46:20] <peloverde> what is this, 1982 [17:46:31] <Dark_Shikari> peloverde: why would you need 4GB of memory for encoding? [17:46:31] <mru> why would an encoder need more than 4GB memory? [17:47:00] <peloverde> Above HD resolutions? [17:47:22] <Dark_Shikari> peloverde: x264 can do 4K without more than 2GB memory [17:47:24] <mru> we're not encoding at 32k just yet [17:47:47] <twnqx> x264 can also to 720p at >2GB :] [17:47:50] <twnqx> do* [17:47:53] <Dark_Shikari> yes, yes, if you want to use rc-lookahead 250 [17:47:55] <Dark_Shikari> for NO REASON WHATSOEVER [17:48:20] <twnqx> full GOP lookahead! [17:48:32] <peloverde> They have a KB article about it, which implies it is an issue for some of their customers [17:48:56] <Dark_Shikari> lol [17:48:57] <mru> customer == idiot [17:49:04] <mru> ms customer doubly so [17:49:22] <peloverde> It just seems silly that their code isn't 64-bit clean [17:49:31] <mru> it's of course possible, perhaps even likely, that the ms encoder is so rubbish it really needs that much memory [17:49:41] <mru> peloverde: silly and predictable [17:50:05] <twnqx> you think there are chances to trade memory for speed? or is it plain bad code? [17:51:06] <Dark_Shikari> there are ways to trade memory for "speed" [17:51:12] <Dark_Shikari> but once you consider cache effects, they're all worthless [17:51:22] <Dark_Shikari> e.g. I tried making a LUT for bit cost of 4x4 dct blocks with CAVLC [17:51:32] <mru> yes, you can trade memory for speed [17:51:32] <Dark_Shikari> it saved a ton of time, but the cache pressure and misses were enough to exactly cancel it out [17:51:36] <mru> give up some speed, use more ram [17:51:40] <Dark_Shikari> lol [17:52:33] <twnqx> you need to run it on one of those parisc monster with HUGE l3 caches [17:52:49] <twnqx> then again, it'll still use to SIMD and higher clock speeds [17:52:50] <mru> and no simd [17:52:53] <twnqx> lose* [17:53:08] <BBB> omg @ libv4l [17:53:35] <mru> what's he getting at? [17:53:46] <mru> is he talking about cameras with mpeg output? [17:54:03] <BBB> issue1816 [17:54:09] <mru> I saw the email [17:54:19] <mru> but it doesn't make much sense [17:54:37] <mru> using a library to perform a few ioctl() calls seems pointless [17:55:13] <thresh> it does some colorspace conversion so you don't need to actually do it in your app [17:55:19] <thresh> (among other things) [17:55:24] <thresh> of course, i don't know if it's fast enough [17:55:38] <mru> great, so you get to convert colourspace twice [17:55:54] <BBB> what I find hilarious is that for any "problem" that Linux developers invent, they will write a new "libXYZ" that will fix it [17:55:59] <BBB> then they advertise it EVERYWHERE [17:56:01] <BBB> USE LIBXYZ [17:56:19] <BBB> reminds me of early days of libalsa [17:56:52] <mru> alsa is crap through and through [17:57:02] <mru> the driver side isn't totally bad [17:57:14] <BBB> they fixed libalsa by making pulseaudio [17:57:19] <BBB> ... [17:57:20] <mru> all the layers they plaster on top in libalsa make it bad [17:57:32] <BBB> I wonder how people will fix pulseaudio [17:57:38] <BBB> I'm sure they will write a gstreamer plugin for it [17:57:39] <elenril> what's so bad about alsa? [17:57:46] <BBB> layeritus [17:57:47] <mru> http://blogs.adobe.com/penguin.swf/linuxaudio.png [17:57:50] <thresh> yeah, IIRC gspca developers moved out all the code to do conversions out of kernel so there was no other chance to get it working except creating a library to do so [17:58:03] <mru> what conversions? [17:58:21] <mru> having colourspace conversion in kernel is obviously wrong [17:58:28] <thresh> colorspace [17:58:31] <mru> that was a mistake in the original v4l "design" [17:58:39] <Dark_Shikari> >implying v4l was designed [17:58:49] <mru> hence the scarequotes [17:59:00] <thresh> http://hansdegoede.livejournal.com/3636.html will probably explain better [17:59:04] <janneg> for example raw bayer data [17:59:04] <thresh> and other hans posts [17:59:10] <kshishkov> BBB: I fixed it - sudo apt-get remove pulseaudio [17:59:15] <janneg> or encoded jpeg [17:59:20] <BBB> kshishkov: I installed macosx [17:59:23] <mru> if raw bayer is all you get from the hw, then that's what the kernel should expose [17:59:27] <BBB> or rather, I bought a mac [17:59:41] <mru> are you insane? [18:00:00] <kshishkov> BBB: that too, but on Linux I had to remove pulseaudio since it screw something [18:00:01] <janneg> and it does now [18:00:19] <mru> I haven't removed pulseaudio [18:00:22] <mru> I never installed it [18:00:25] <mru> never will [18:00:45] <BBB> IIRC pulse was my reason to stop developing gnome [18:01:19] <kshishkov> and not millions of crappy plugin libs required everywhere? [18:01:27] <BBB> that too [18:01:50] <kshishkov> the only good point about Gnome that it sucks differently from KDE [18:01:53] <BBB> libv4l is a silly idea, userspace devices seem more likely [18:02:03] <BBB> libalsa same thing [18:02:26] <elenril> kde3 didn't suck so much [18:02:47] <thresh> userspace devices? [18:02:49] * Kovensky thinks OSSv4 is the only sane thing [18:03:03] <peloverde> The OSS team has shown they aren't trustworthy [18:03:44] <thresh> the thing i miss most in linux is /dev/ethN [18:03:50] <kshishkov> WinAPI is saner - for each block WavePrepareDevice(); WaveWriteOutput(); WaveUnprepareDevice(); [18:03:51] <Kovensky> peloverde: ? [18:03:59] <BBB> thresh: you know how certain things in /dev/ can run in userspace [18:04:07] <BBB> thresh: open("/dev/that"); [18:04:23] <BBB> instead of v4l_open("/dev/video"); [18:04:45] <mru> mmap(/dev/mem) ftw [18:05:01] <peloverde> Kovensky, They changed the license when they were popular and tried to sell closed drivers [18:05:06] <BBB> point being, writing a userspace WRAPPER for kernel "bugs" is always wrong [18:05:14] <kshishkov> well, Gatos driver creators proposed to use some internal script command language instead of ioctls too [18:05:30] <mru> and look how far it got them [18:05:33] <Kovensky> <@peloverde> Kovensky, They changed the license when they were popular and tried to sell closed drivers <-- oh, that [18:05:56] <Kovensky> I thought it was some other problem after they re-opened ._. [18:06:10] <kshishkov> yes, ALSA [18:06:47] <kshishkov> since evil SuSe devs pushed it into kernel nobody cares much about OSS [18:07:09] <mru> greg kh is very evil [18:07:32] * Kovensky is confuzzled [18:07:33] <kshishkov> who's that? [18:07:36] <BBB> the oss4 (?) guys did a good effort to try to push it [18:07:39] <mru> the evil suse dev [18:07:46] <BBB> they contacted me and offered oney for me to write gst plugins [18:07:50] <BBB> *money [18:07:52] <kshishkov> well, suse is known for other great evils [18:07:55] <BBB> I almost did it [18:08:12] <BBB> maybe I should've [18:08:21] <mru> I don't give a toss about that patent deal they struck with ms [18:08:22] * Kovensky only knew greg kh as the staging guy [18:08:49] <mru> more recently he pushed "devtmpfs" against half the maintainer's will [18:09:09] <mru> devfs was bad the first time, it'll be bad every time [18:09:46] <mru> oh, and he's a freetard of highest class [18:10:14] <kshishkov> mru: I heard you also enjoyed chatting with Joerg Schillig [18:10:34] <Kovensky> lol [18:10:35] <mru> hehe [18:10:42] <mru> schilling is fun [18:10:50] <mru> one of the best trolls ever [18:11:17] <kshishkov> have you told him how you record your DVDs? [18:11:30] <elenril> is that the cdrtool guy? [18:11:33] <mru> yes [18:17:32] <janneg> cdrecord [18:18:13] <Dark_Shikari> ok, so this is getting more and more weird [18:18:18] <jai> thats part of crtools [18:18:21] <jai> *cdrtools [18:18:22] <Dark_Shikari> yesterday I spent 30 minutes talking about low latency VNC-style streaming with an autodesk guy [18:18:30] <Dark_Shikari> 15 minutes later, he says "want to fly up to san francisco?" [18:18:32] * jai remembers the whole cddl thing [18:18:51] <Dark_Shikari> apparently they're using ultra-low-latency video streaming for demos of their products [18:19:03] <Dark_Shikari> so you can try autocad without buying it or downloading a gigantic demo of fail [18:20:46] <Dark_Shikari> well, whatever it is, I'm getting a lot of free junkets [18:21:06] <kshishkov> yes, so he wants low-latency wireless communication with you [18:21:14] <jai> Dark_Shikari: buy everyone a beer :) [18:21:30] <Dark_Shikari> lol [18:21:40] <Dark_Shikari> technically, I'm still a bit too young ;) [18:21:51] <kshishkov> emigrate to Russia [18:21:53] <Dark_Shikari> (isn't the US great) [18:21:58] <jai> Dark_Shikari: you can have yourself some cranberry juice [18:22:11] <Dark_Shikari> lol [18:22:53] <kshishkov> Dark_Shikari: in Russia you also have bottled water with local vodka brands (produced by them) [18:22:53] <BBB> so you can vote [18:22:56] <BBB> carry guns [18:22:59] <BBB> but you cannot drink? [18:23:01] <Dark_Shikari> correct! [18:23:03] <Dark_Shikari> US is great. [18:23:03] <BBB> LOVE this country [18:23:06] <BBB> :) [18:23:23] <kshishkov> BBB: I'd prefer working Systembolaget to that [18:23:29] <BBB> let's not forget the drive car & have sex [18:23:58] <BBB> thank god they don't drive manuals here [18:24:05] <BBB> imagine the accidents [18:24:17] <jai> BBB: unlike your home country, in this case the constitution was drafted by prudes :) [18:24:56] <kshishkov> BBB: I've heard that the most terrible drivers are French (even worse than Russians) [18:25:05] <jai> BBB: btw, we drive manual transmission here [18:25:24] <mru> BBB: yeah, driving a manual while having sex is dangerous [18:25:27] <kshishkov> jai: and you still have original Jeep model in production as well [18:25:35] <jai> kshishkov: of course :) [18:25:42] <mru> american gals can only handle one stick at a time, apparently [18:26:05] <BBB> okaaaaaaaaaay [18:26:14] * BBB takes a break [18:26:20] <mru> too rude for this channel? [18:26:21] <jai> lol [18:26:26] <BBB> :) [18:27:16] <jai> #ffmpeg-devel | age-limit >=18 [18:27:30] <kshishkov> BBB: you have an opportunity to talk about voice codecs now [18:27:36] <mru> hey, it's not like I'm posting ascii-porn... [18:27:46] <kshishkov> mru: IIRC you did once [18:27:54] <mru> in this channel? [18:27:56] <jai> mru: throw some of that in too once in a while [18:28:06] <mru> I've done that in other channels [18:28:19] <mru> but I don't think you're in those [18:33:44] <CIA-92> ffmpeg: victor * r22567 /trunk/doc/general.texi: Add compilation hints for Cygwin 1.7 and remove the ones for 1.5 [18:36:58] <jai> doesnt 1.7 use a buggy gcc by default? [18:38:25] <kshishkov> don't they all? [18:38:34] <kshishkov> along with crippled libs [18:39:55] <ramiro> and it's rather annoying to remove the default gcc... [18:40:47] <ramiro> a bunch of packages implicitly include gcc. there is no simple way to remove them besides cycling through "install", "update", "keep", "skip". if you click once too much, you have to go through "install" again, which re-selects all gcc packages... [18:41:12] <mru> gaaah, I hate the cygwin installer [18:41:22] <mru> thankfully I'll probably never have to touch it again [18:41:35] <ramiro> they should port apt-get to cygwin. [18:41:46] <mru> I'm not a fan of that either [18:42:01] <ramiro> it's better than cygwin's installer at least. [18:42:13] <mru> even rpm beats cygwin [18:43:05] <jai> ramiro: why dont people just use mingw+msys? [18:43:18] <mru> probably because mingw doesn't actually work [18:43:30] <mru> cygwin looks like and behaves almost like unix [18:43:33] <peloverde> mingw + msys is a mess to install and update [18:43:45] <jai> has worked so far for me [18:43:48] <jai> peloverde: ok [18:43:49] <ramiro> and lacks a handful of functionality... [18:43:57] <mru> it's dreadfully slow, and some things don't work quite right [18:44:11] <jai> peloverde: tbh, i update it once every 6 months or so :) [18:44:16] <mru> but if you're stuck on a windows machine you can at least get some work done [18:44:26] <jai> mru: i always found cygwin to be much slower in comparison [18:44:33] <mru> I'm talking about cygwin [18:44:45] <mru> mingw may be a hair faster but lacks much more functionality [18:44:46] <jai> ah [18:44:55] <peloverde> for cygwin you download setup.exe and select what you want from the package manger, for mingw I always wind up needing 2 dozen installers and zip files to get what i need [18:45:10] <mru> sockets and pipes tend to break outside of cygwin [18:45:49] <ramiro> peloverde: I only need one installer (msys itself). the rest is just tar xfvj... [18:45:58] <kshishkov> do cygwin-compiled progs still require cygwin1.dll? [18:46:04] <mru> yes [18:46:05] <ramiro> kshishkov: you can cross-compile to mingw [18:46:12] <mru> that's where all the magic lives [18:46:13] <peloverde> you still need to track down all the tarballs and update them manually [18:46:28] <kshishkov> ramiro: I've always used msys+mingw [18:46:31] <mru> you can easily build for non-cygwin under cygwin [18:46:45] <ramiro> peloverde: yes, that's true... annoying, but I know the subset needed for ffmpeg, and that's all I need =) [18:47:14] <jai> i think coreutils and zlib should be enough? [18:47:22] <jai> on top of stock msys [18:47:24] <ramiro> well, now that virtualbox is good enough on windows, there's no reason to use either msys or cygwin... [18:47:41] <mru> there's also no reason to use windows in the first place [18:47:44] <ramiro> jai: now yes (actually only pr.exe from coreutils) [18:47:56] <peloverde> office in wine is still super buggy for me [18:48:03] <kshishkov> mru: not all people are free [18:48:04] <peloverde> ^ = reason to use windows [18:48:08] <mru> why would you run office? [18:48:10] <jai> except for QA which you have to do as windows maintainer ;) [18:48:13] <jai> ramiro: ^ [18:48:26] <peloverde> mru, MPEG working documents are all .doc [18:48:38] <mru> they load fine in openoffice [18:48:47] <peloverde> The always come up mangled for me [18:49:06] <kshishkov> missing fonts maybe [18:49:21] <mru> I always export to pdf first thing [18:49:28] <jai> 3gpp specs seemed to be a bit off when it comes to layout in openoffice [18:49:32] <jai> though its readable [18:49:36] <mru> I cannot stand reading a document in ooffice or msword [18:50:37] <kshishkov> and some people use it for reading _books_ [18:50:50] <ramiro> -freorder-functions? I don't need that for the fate boxes... [18:52:43] <peloverde> This is not usable at all: http://i.imgur.com/yMDKG.png [18:53:12] <mru> where's the file? [18:53:31] <Kovensky> -fomg-fast? [18:55:23] <peloverde> That one isn't publicly available, here is the 3GPP version it does the same thing: http://www.3gpp.org/ftp/Specs/archive/26_series/26.404/26404-900.zip [18:56:39] <peloverde> My OO.o rendering of it: http://i.imgur.com/YUFaz.png [18:56:53] <peloverde> abiword and kword do no better [18:57:03] <ramiro> peloverde: and google docs? [18:57:19] <peloverde> ramiro, google docs is terrible too [18:57:21] <kierank> seems to work ok in staroffice (but might be because i'm on windows) [18:57:22] <jai> i still somehow manage 3gpp specs with abiword though :) [18:57:53] <kshishkov> so it may be fonts issue after all [18:58:50] <peloverde> OO.o should be able to handle it with their symbol font [18:59:28] <kierank> it appears as a picture, not an equation in staroffice for some reason [18:59:37] <mru> hmm, I get a few <?> characters [19:01:12] <mru> gaah, oo is stuck in a loop popping up a message complaining about bad JRE [19:01:35] <kshishkov> it's true though [19:04:40] <mru> all the bad characters inside some kind of "picture" [19:05:14] <peloverde> Here is the google docs pitiful attempt: http://i.imgur.com/Mt6hl.png [19:05:14] <kshishkov> IIRC it also renders equations as vector graphics [19:07:36] <peloverde> I also tried pulling the updated ttf-opensymbol from the latest OO.o nightly [19:08:06] <kshishkov> it may need original symbol ffonts instead [19:10:23] <mru> I have every font package in gentoo installed, and some more [19:11:08] <peloverde> (I also have a bunch of opentype fonts that cause OO.o to shit itself when it touches them) [19:15:17] <BBB> Vitor1001: did you have a chance to look at that crazy rdft scheme yet? [19:16:50] <Vitor1001> BBB: I gave a look, but didn't yet got what that was supposed to do :( [19:17:27] <Vitor1001> It certainly do a phase shift [19:17:56] <Vitor1001> ie., writing everything as a sum of sinuses and then changing all the sinuses to cosinus [19:18:13] <peloverde> I thought we established it was a hilbert transform? (or is this something else)? [19:18:16] <Kovensky> math D: [19:18:22] <BBB> peloverde: something else, I think [19:18:31] <BBB> peloverde: or maybe not [19:18:32] <BBB> wait [19:18:37] <BBB> this was the complex code [19:18:42] <BBB> was that a hilbert? [19:18:56] * Vitor1001 has to read what a hilbert transform is [19:18:59] <Vitor1001> :( [19:19:13] <Vitor1001> Sorry, but today I'm somewhat you of time... [19:19:14] <kshishkov> it's all on wikipedia [19:19:16] <peloverde> The hilbert changed the reals to imaginary in the fourier domain then inverse transformed [19:19:37] <kshishkov> what for? [19:19:42] <Vitor1001> peloverde: Than it is it, because that is what the code does... [19:19:46] <Vitor1001> bbl... [19:28:55] <BBB> is it because of that convolution stuff at the end of the wikipedia article? [19:29:03] <BBB> because that'd fit the numbers I see after the phase shift [19:30:03] <BBB> which are maximal (~1.0) for the peaks (left of the DFT approx.) and lows (right of the DFT approx.), i.e. the result would be that the DFT approx. is shifted to become more like the actual 2/(n*pi) [19:30:14] <BBB> but as always, I have no idea what I'm doing [19:34:29] <kshishkov> lab rule - if you don't know what you're doing then do it thoroughly [19:34:57] <peloverde> Honestly, we always did Hilbert transform the last week of the semester so I never really learned it [19:35:12] <DonDiego> bye [19:35:15] <kshishkov> always? [19:35:22] <peloverde> I had it in two classes [19:35:39] <peloverde> Signal Processing and Communication Systems [19:36:01] <kshishkov> we had only Hadamard transform (mentioned once) at Computer Graphics [19:36:51] <mru> I only remember hilbert mentioned in passing [19:37:02] <peloverde> I vaguely remember needing a hilbert transform for single sideband modulation [19:43:05] <BBB> peloverde: but what does it do? [19:43:39] <BBB> is it a particularly good way of removing noise equally without caring about "level" of noise per frequency? [19:43:52] * BBB mumbles hocuspocus [19:43:58] * BBB needs to read a signalprocessing book, yes I know [19:44:15] <kshishkov> dspguide.com or something [19:44:39] <kshishkov> all chapters in PDF, free download IIRC [19:47:20] <BBB> hilbert only occurs once [19:47:23] <BBB> and that's a mention [19:47:26] <BBB> without any information :) [19:58:15] <peloverde> I don't know, i haven't done anything with it in a long tim [19:58:18] <peloverde> *time [19:58:42] <kshishkov> everybody else simply haven't done anything with it [20:02:04] <peloverde> "You use the Hilbert transform to extract instantaneous phase information, obtain the envelope of an oscillating signal, obtain single-sideband spectra, detect echoes, and reduce sampling rates." [20:02:30] <_av500_> peloverde: svn add hilbert.c? [20:02:34] <kshishkov> envelope or echoes seems plausible [20:03:01] <thresh> http://farm5.static.flickr.com/4014/4438147379_4be8e401d3.jpg ta-duh. [20:03:34] <_av500_> thresh: you hilbert transformed your screen? [20:04:16] <thresh> kind of. i'd call it 'punch transform'. [20:04:38] <_av500_> a dirac impulse? [20:06:32] <peloverde> since the output is eventually treated as an angle i'm pretty sure it's extracting phase [20:07:42] <ramiro> if we create a LinkedIn account (and Facebook and whatnot) for FFmpeg's lists, will that make the lists immune to invitations? [20:08:54] <peloverde> Is there an arctan in there at all? [20:09:45] <kshishkov> why? it has poles [20:10:56] <peloverde> instantaneous phase is atan2(H(f)(t), f(t)) [20:11:24] <peloverde> Can I see that chunk of code again? [20:57:42] <bcoudurier> hi guys [21:11:32] <elenril> hi bcoudurier's onjoin script [21:11:42] <andoma> :) [21:11:47] <elenril> bcoudurier: can you review/apply Honoome's patch for s/author/artist in movdec? [21:12:37] <bcoudurier> oh, sorry but who is Honoome ? [21:12:56] <elenril> the other Diego [21:14:10] <elenril> Date: Fri, 19 Feb 2010 14:42:52 +0100, Fix metadata mapping for author/artist [21:14:20] <bcoudurier> movdec is good [21:14:31] <bcoudurier> movenc is not, "auth" should be author obviously [21:14:41] <ohsix> bcoudurier: Honoome = flameeyes from gentoo [21:15:06] <elenril> well we don't have an 'author' tag [21:15:54] <elenril> btw why isn't all metadata exported in movdec? [21:23:46] <CIA-92> ffmpeg: mru * r22568 /trunk/configure: [21:23:46] <CIA-92> ffmpeg: configure: do not use $_ [21:23:46] <CIA-92> ffmpeg: Both bash and ksh abuse this variable even in POSIX mode, leading [21:23:46] <CIA-92> ffmpeg: to unpleasant surprises. [21:23:46] <CIA-92> ffmpeg: mru * r22569 /trunk/ (10 files in 10 dirs): Move arch-specific makefile parts into $arch/Makefile [21:23:47] <CIA-92> ffmpeg: mru * r22570 /trunk/libavcodec/ (6 files in 6 dirs): Simplify arch-specific object file lists [21:46:25] <CIA-92> ffmpeg: mru * r22571 /trunk/libavformat/utils.c: [21:46:25] <CIA-92> ffmpeg: Fix erroneous behaviour when format probe hits end of file [21:46:25] <CIA-92> ffmpeg: If the format probe hits end of file, do not add the error code [21:46:25] <CIA-92> ffmpeg: to the buffer position. This is obviously wrong, and with a [21:46:25] <CIA-92> ffmpeg: small input file would cause a negative buffer overflow. [21:46:26] <CIA-92> ffmpeg: Fixes issue 1818. [21:46:52] <BBB> shit he left [21:52:40] <mru> who? [21:55:09] <BBB> peloverde [21:55:45] <BBB> I think he's right, and the specific application appears to be noise reduction using an iterative wiener filter (??), at least I have a paper describing that which appears to match my implementation pretty closely [22:17:20] <superdump> BBB: does that involve throwing sausages at something? [22:29:13] <bcoudurier> Yuvi, are you there ? [22:29:24] <Yuvi> bcoudurier: yo [22:29:33] <bcoudurier> elenril, feel free to expert everything but many atoms contain only data [22:30:05] <bcoudurier> I've merged your patch and fixed problems [22:30:05] <bcoudurier> thanks for the work [22:30:05] <bcoudurier> I've a few concerns though [22:30:05] <Yuvi> yay [22:30:07] <bcoudurier> since granule must be strictly monotone [22:30:13] <bcoudurier> this seriously reduce the packing [22:30:21] <Yuvi> only within a stream [22:30:22] <bcoudurier> no [22:30:22] <bcoudurier> oggz-validate complains [22:30:29] <bcoudurier> if video granule < audio granule [22:30:34] <bcoudurier> err > [22:31:14] <bcoudurier> so except if it is a oggz-validate problem [22:31:14] <bcoudurier> it's not possible [22:31:14] <bcoudurier> what do you think ? [22:35:44] * Terminating due to: TERM [22:36:01] * /join #ffmpeg-devel ... [22:36:03] *** 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. [22:36:03] *** TOPICINFO: superdump!~rob@unaffiliated/superdump, 1267604523 [22:36:21] <_av500_> but granule is opaque to the muxer, no? [22:36:25] <bcoudurier> Ogg does not have a concept of 'time': it only knows [22:36:25] <bcoudurier> about sequentially increasing, unitless position markers. [22:36:26] <mru> yes [22:36:30] <bcoudurier> rfc [22:37:21] <_av500_> so it cannot know granule relatipnshop btween streams [22:37:33] <mru> that never stopped xiph before [22:37:51] <_av500_> :) [22:39:52] <mru> "logical stream data pages are arranged in a physical bitstream in strict non-decreasing order by chronological absolute time as specified by the granule position" [22:39:56] <mru> http://xiph.org/ogg/doc/ogg-multiplex.html [22:40:09] <Yuvi> anyway, my only argument for interleaving based on start time was that I thought players (vlc) didn't like the additional buffering needed for audio [22:40:32] <mru> nobody likes ogg [22:41:18] <bcoudurier> well actually the packing is not that bad [22:41:26] <bcoudurier> you don't need a parser to extract frames [22:41:31] <bcoudurier> not like PS or TS [22:41:31] <mru> uh? it's the most terrible one ever devised [22:41:41] <bcoudurier> PS and TS add parser overhead [22:41:45] <mru> you don't need that with mp4 of mkv either [22:41:50] <bcoudurier> nope [22:41:54] <bcoudurier> I'm comparing to PS and TS [22:42:03] <mru> that's a bad idea [22:42:07] <bcoudurier> the PES packing is not convenient [22:42:08] <mru> they solve a different problem [22:42:14] <Yuvi> oh [22:42:27] <bcoudurier> especially when startcodes are hard to find [22:42:32] <Yuvi> the issue with the file I was trying is that all audio pages had a granulepos of 0 [22:42:41] <mru> that's not very valid [22:44:17] <mru> "the only requirement is that page n of a logical bitstream follow page n-1 in the physical bitstream. There are no restrictions on intervening pages belonging to other logical bitstreams" [22:49:04] <mru> http://xiph.org/ogg/doc/oggstream.html [22:49:04] <mru> lovely inconsistency [22:49:04] <mru> non-monotone muxing also breaks bisection seeking of course [22:49:04] <_av500_> just do it per stream :) [22:49:04] <Yuvi> _av500_: that's actually more work in the muxer [22:49:04] <Yuvi> well, than what happens now [22:49:04] <Yuvi> bcoudurier: anyway the answer from #theora is that granule interleaving is a must regardless of the rfc [22:49:04] <mru> and regardless of that other page explicitly stating the opposite [22:49:04] <bcoudurier> Yuvi, between streams ? [22:49:04] <Yuvi> bcoudurier: yep [22:49:04] <bcoudurier> ah ok [22:49:04] * Terminating due to: __DIE__ [22:49:56] * /join #ffmpeg-devel ... [22:49:56] *** 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. [22:49:56] *** TOPICINFO: superdump!~rob@unaffiliated/superdump, 1267604523 [23:07:25] <twnqx> oh wow [23:07:25] <twnqx> a file that freezes the h264 decoder [23:09:09] <twnqx> [h264 @ 0xad3aa0]illegal short term buffer state detected??,?% 8 0 [23:09:09] <twnqx> mh [23:09:09] <twnqx> oh wow [23:09:09] <twnqx> seeking in this file is not a good idea either :P [23:25:52] * Terminating due to: __DIE__ [23:52:41] * /join #ffmpeg-devel ... [23:52:43] *** 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. [23:52:43] *** TOPICINFO: superdump!~rob@unaffiliated/superdump, 1267604523 [23:53:27] <mru> bcoudurier: who's that? [23:53:53] <bcoudurier> someone in #theora [23:54:15] <iive> lol [23:54:44] <mru> someone proved him wrong?

1 0

IRC log for 2010-03-15
by irc＠mansr.com 16 Mar '10

16 Mar '10

[00:00:40] <CIA-92> ffmpeg: aurel * r22534 /trunk/libavformat/ (9 files): [00:00:40] <CIA-92> ffmpeg: move ff_url_split() and ff_url_join() declarations to internal.h [00:00:40] <CIA-92> ffmpeg: those functions are not part of the public API [00:20:12] <CIA-92> ffmpeg: aurel * r22535 /trunk/libavformat/matroskadec.c: matroskadec: use more appropriate error code [02:33:13] <CIA-92> ffmpeg: astrange * r22536 /trunk/ffmpeg.c: ffmpeg: Factor out redundant sync_ipts calculation [02:34:37] <CIA-92> ffmpeg: astrange * r22537 /trunk/ffmpeg.c: ffmpeg: Combine variable declaration and definition [06:27:39] <KotH> ohayou gozaimasu, minna-san [06:28:14] <kshishkov> おっす [06:53:56] <pJok> morgens :) [06:54:08] <jai> morning pJok :) [06:54:15] <thresh> moroning [06:54:22] <jai> O_O [06:55:11] <pJok> mornings jai :) [06:55:14] <kshishkov> goda morgnar [06:57:00] <pJok> mornings kshishkov :) [07:59:28] <ohsix> why are ffts so magical :( [07:59:50] <ohsix> they can do all sorts of junk, i'd like to understand their primacy beyond the basic utility [08:00:06] <ohsix> some jerks use it for multiplying huge numbers, and i have no clue how [08:01:08] <Dark_Shikari> ohsix: the concept is simple [08:01:17] <Dark_Shikari> 1) FFTs are magic O(n*log(n)) [08:01:29] <Dark_Shikari> 2) there's a trick to do multiplication in the FFT domain that's faster than normal [08:01:39] <Dark_Shikari> 3) FFTs are magic nlogn [08:01:55] <ohsix> is the magic summingn them in scale space then transforming them back? [08:02:01] <Dark_Shikari> basically yes I think [08:02:13] <ohsix> hm, i didn't think about that [08:02:22] <ohsix> that works for powers and a bunch of junk too [08:03:04] <KotH> also keep in mind, that exp() and log() in a ring are nothing else than a FT [08:03:11] <ohsix> i posted a bug for the free picture thing too, NONSENSICAL SYLLABLES AND PREPOSTEROUS GAY ACTS [08:03:19] <ohsix> haha that is not it; darn my clipboard [08:03:29] <ohsix> https://bugzilla.gnome.org/show_bug.cgi?id=612773 [08:03:44] * KotH ponders whether to ban ohsix for this outragous comment ;) [08:04:14] <Dark_Shikari> lol [08:04:32] <ohsix> KotH: that is the primer i was looking for, i didn't think about that; i didn't understand the transform anyways, just some uses, but if its just a power series then i guess thats how it goes [08:05:15] <ohsix> there was a clever hack i saw some years ago that used logarithms for everything too [08:05:31] <KotH> ohsix: uhmm.. i think you first want to learn all the properties of FT, LT and ZT, then properties of groups and rings [08:05:43] <ohsix> i will when i need to [08:05:43] <KotH> ohsix: the rest is pure combination of these different properties [08:06:27] <ohsix> how they do multiplcations and shape fitting was just something i figured i'd ask about; or go without knowing at that moment [08:09:02] <KotH> which reminds me.. i should somewhen relearn LT and ZT [08:09:31] * KotH forgot everything about them over the years [08:09:34] * KotH blames mru [08:09:44] <ohsix> i guess correlation comes cheap when its all an addition, hm, and if you transform it back you get magic [08:10:33] <av500> KotH: same here [08:12:28] <KotH> ohsix: a correlation is a convolution operation of two signals [08:12:36] <KotH> ohsix: which is very expensive [08:12:58] <KotH> ohsix: a convolution in time space is a the same as a multiplication in frequency space though [08:14:21] <KotH> ohsix: http://en.wikipedia.org/wiki/Fourier_transform#Properties_of_the_Fourier_tr… [08:16:44] <ohsix> my understanding is too patch to actually enjoy that, i just know some terms of art [08:25:18] <KotH> it doesn't matter whether your understanding is patchy or not. to enjoy that kind of stuff you need a form of mathematical masochism [08:25:38] <ohsix> heh knowing what something says is pretty satisfying [08:25:57] <ohsix> especially if it made your eyes glaze over for a significant amount of time :P [08:26:48] <ohsix> theres a lot of open source math packages :\ [08:33:01] <KotH> like ffmpeg? ;) [08:33:45] <ohsix> nah like yorick and octave [08:34:17] <ohsix> they're probably all good, but it gets pretty imperative when you want to do anything complex and you have to pick one :\ [08:36:00] <CIA-92> ffmpeg: mstorsjo * r22538 /trunk/configure: Add dependencies used by the RDT and ASF/RTP code [08:49:50] <CIA-92> ffmpeg: benoit * r22539 /trunk/libavformat/riff.c: [08:49:50] <CIA-92> ffmpeg: riff: don't pad extradata when writing ASF. [08:49:50] <CIA-92> ffmpeg: Patch by Anton Khirnov mirror(moc liamg saksyw) [08:50:36] <ohsix> that guy should just use a gmail label :O [08:50:37] * thresh would write a bot that will deobfuscate e-mails ffmpeg commit messages and spam those [08:51:13] <kshishkov> good luck with my commits [08:54:14] <hyc> URLProtocol handlers are kinda braindead, when you have multiple variants of a base protocol... [08:57:46] <wbs> hyc: quick question: does your librtmp implementation support sending of video to a rtmp server? [08:58:01] <hyc> wbs: not at the moment [08:58:09] <hyc> but should be simple enough to add [08:58:11] <wbs> ok [08:58:12] <hyc> who uses that? [08:58:25] <wbs> I may use it from time to time [08:58:56] <hyc> what code do you use for it? what does the expected API look like? [08:59:02] <hyc> obviously you have to mux it as FLV first [08:59:47] <wbs> yes, I open a flv muxer and open a rtmp://server/app/name url for writing [09:00:26] <wbs> or just ffmpeg -i foo -f flv rtmp://server/app/name [09:00:31] <wbs> add -re to that, too [09:00:59] <hyc> hm, cool. don't you need some kind of authentication to open a seesion with the server? [09:01:12] <wbs> that's fully up to the server [09:01:25] <wbs> for some servers, the url is the secret [09:01:34] <hyc> right. but the current libavformat implementation has no security support at all [09:01:55] <wbs> so you publish to rtmp://server/app/userspecificsecret, and the server then makes the stream available on some other publicly available url [09:02:01] <hyc> ahh. [09:02:34] <hyc> boy, *that'*s secure... ;) [09:02:41] <wbs> :-) [09:03:31] <hyc> I'll cobble something together. have nothing to test against though. [09:07:37] <wbs> wowza test setups has something similar out of the box (or easy to enable at least, iirc), that allows everybody (or only localhost?) to send to rtmp://server/live/<whatever> [09:07:48] <wbs> and then you can watch it at the same url [09:09:32] <hyc> ah I see, they have a free developer edition [09:10:32] <hyc> hm, since you're actually using this code already - does ffplay work with rtmp urls for you? just hangs for me. which is why I just decided to sidestep all of that code. [09:11:15] <wbs> yes, it works for me. not with all servers, though, but at least with wowza (and reportedly also with FMS) [09:11:30] <wbs> there's some problems when handshaking with red5 iirc [09:11:53] <hyc> well, rtmpdump works with everything [09:12:24] <hyc> doesn't seem to be worth my time to debug one when we have a fully working other [09:12:56] <hyc> I'll get rtmp_write working in a bit then [09:14:47] <wbs> well, in some setups, less external dependencies is a plus. but if you get it functionally equivalent on all accounts, I guess its worth considering [09:16:11] <hyc> getting write support is trivial. so the question is simply do you want rtmpe/rtmps support or not. [09:16:19] <hyc> if yes, then you need crypto libraries. [09:17:28] <hyc> we can probably rewrite those bits to use gnutls/gcrypt if necessary [09:17:40] <hyc> tho IMO, gnutls is too buggy to rely on [09:18:18] <wbs> rtmpe/rtmps isn't a requirement for me, but if it can be enabled optionally, it's a plus of course [09:18:53] <wbs> but please don't take my opinions as representative for the other developers :-) [09:19:28] <hyc> no, I totally get it. I'd avoid adding new dependencies as much as possible [09:19:55] <wbs> is librtmp generally available (e.g. in debian/ubuntu repos), btw? [09:20:21] <hyc> as far as I know, no one has pkg'd it on its own yet. [09:20:33] <hyc> so it's implicitly included in their rtmpdump pkgs [09:21:10] <wbs> ah, well that's a bit of a hurdle for general acceptance I think. if I'm going to use external libraries, that should be something that I can apt-get and forget [09:21:37] <hyc> eh... no one said it needs to be an external dependency [09:21:48] <hyc> after all, it's homed on the mplayer servers [09:21:54] <wbs> ah, so you're going to bundle the librtmp code within libavformat? [09:22:09] <hyc> just another external svn reference [09:22:17] <hyc> I think that would be the easiest way to go [09:22:25] <wbs> ewww :-) [09:22:42] <hyc> well, that's getting ahead of ourselves. [09:22:51] <hyc> first someone has to decide this is ok to incorporate [09:22:59] <wbs> yeah, true [09:23:37] <hyc> Compn raised the question a few months ago [09:23:39] <hyc> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-September/075579.html [09:23:46] <hyc> and it looks like it went nowhere [09:24:02] <hyc> perhaps because no one wanted to take the time to investigate or write the code [09:24:24] <hyc> now I've done that, we'll see what obstacles remain [09:29:49] <kshishkov> hyc: could be me [09:32:23] <hyc> kshishkov: I would have expected you. ;) but you didn't reply to that email thread [09:35:04] <kshishkov> haven't got right words yet [09:36:33] <kshishkov> it's not that I'm against having fully working RTMP implementation but the way we get it should be discussed [09:38:59] <hyc> yes. but the discussion in September went nowhere. possibly because there was no clear idea of what to do. [09:39:20] <hyc> Now we have a straw-man implementation to talk about in concrete terms. [09:40:10] <kshishkov> straw-man == dummy? [09:41:22] <hyc> basically, yeah. it was thrown together quickly to get something working [09:41:34] <kshishkov> I know that rtmpdump works [09:41:55] <hyc> it shows there are still problems (e.g. seek) that need to be thought about [09:42:00] <kshishkov> but I'd like to know what's missing from current lavf implementation [09:43:08] <hyc> well, there's something wrong with the handshake, it hangs when trying to connect to a test rtmplite server [09:43:30] <hyc> it doesn't have the buffer-empty recovery logic that we added to rtmpdump [09:43:52] <kshishkov> ah [09:43:57] <hyc> and it obviously is missing all of the crypto and tunneling support [09:44:27] <kshishkov> yes, that's why you should have your glue code fro rtmpt/rtmpe/whatever [09:44:31] <kshishkov> bbl [10:30:30] <CIA-92> ffmpeg: mstorsjo * r22540 /trunk/libavformat/avformat.h: [10:30:30] <CIA-92> ffmpeg: Add a new field AVFormatContext.start_time_realtime [10:30:30] <CIA-92> ffmpeg: Currently intended to be used by the RTP muxer [10:31:25] <CIA-92> ffmpeg: mstorsjo * r22541 /trunk/doc/APIchanges: Add APIchanges entry for AVFormatContext.start_time_realtime [10:37:19] <CIA-92> ffmpeg: mstorsjo * r22542 /trunk/libavformat/ (utils.c internal.h): Move the NTP offset definitions to internal.h [10:38:01] <CIA-92> ffmpeg: mstorsjo * r22543 /trunk/libavformat/rtpenc.c: Use AVFormatContext.start_time_realtime in the RTP muxer [11:47:05] <superdump> does it really make sense that michael is talking about x86 asm maintenance when he has old cpus and it seems (from some mailing list comments) he prefers to actually use the older of those which is older than a p4 dual or something [11:47:31] <pross-au> you really believe that 'dump [11:47:39] <superdump> x86 asm maintenance without using modern x86 cpus that the majority of users have seems a bit weird to me [11:47:43] <superdump> believe what? [11:47:58] <jai> lol @ 'dump [11:48:09] <superdump> yes, i do really believe that michael develops on something older than a p4 dual [11:48:14] * kshishkov waves [11:48:18] <superdump> hello kshishkov [11:49:04] <pross-au> Ok [11:49:08] <Yuvi> I think his laptop is a yonah [11:49:14] <superdump> from my perspective, i would be happy for some hardcore modern x86 simd instruction set optimisation [11:49:16] <kshishkov> that was just to remind you there are some FFmpeg devs with old HW and not complaining about it [11:49:22] <Yuvi> or merom, I forget [11:49:39] <superdump> kshishkov: understandable that you don't complain about it if only old stuff is maintained [11:50:35] <superdump> Yuvi: mmm, i think it's a pentium D branded thing whatever it is [11:51:14] <superdump> but still on the mailing list, michael said something like he'd have to fire up his pentium D machine to run some tests which made it sound like while he has the newer cpu, he uses whatever he had before [11:51:21] <kshishkov> mine fastest CPU is PowerPC 1.42GHz again [11:52:06] <superdump> Dark_Shikari and pengvado have done a great job with the asm in x264 [11:52:11] <pross-au> kshishkov: my daily rig is a 1.6Ghz dothan [11:52:20] <superdump> it would be nice if ffmpeg was at the same level and up to date [11:52:30] <superdump> but obviously that will take time and effort [11:52:33] <superdump> and expertise [11:52:35] <Yuvi> probably http://en.wikipedia.org/wiki/Pentium_Dual-Core#Merom-2M since he does 64-bit iirc [11:52:49] <kshishkov> why not ask directly? [11:53:28] <kshishkov> and I think if somebody can offload him of x86 maintainance and Michael is willing it would be a very good thing to do [11:53:49] <superdump> well that has SSSE3 [11:54:09] <twnqx> kshishkov: i removed an athlon XP 1800+ from its case yesterday, wanna have? :P [11:54:11] <superdump> mmm [11:54:26] <superdump> someone with ninja x86 asm skills [11:54:33] * superdump looks at pengvado and Dark_Shikari [11:54:57] <kshishkov> twnqx: I don't have a place to fit it anyway. MacMini with aforementioned PowerPC is also my biggest computer case too [11:55:04] <twnqx> :o [11:55:24] <twnqx> it doesn't need a case anyway :P [11:55:26] <superdump> just run it open [11:55:31] <superdump> :) [11:55:57] <twnqx> i'll even drop in a fitting AGP card [11:56:03] <kshishkov> superdump: only if you manage to solder it somewhere [11:56:11] <superdump> why solder it? [11:56:26] <kshishkov> no socket for such CPU [11:57:06] <kshishkov> also quite probably all my CPUs are soldered to MB [11:57:25] <superdump> maybe i inferred wrongly but i assumed twnqx upgraded the motherboard/cpu/ram and just kept other stuff + case [11:58:07] <twnqx> yeah [11:58:16] <twnqx> gfx too :P [11:58:26] <twnqx> got a gf 4400 with it [11:58:36] <pross-au> kshishkov: do you have a desoldering station [11:58:37] <twnqx> i have WAY to many obsolete comps [11:58:49] <kshishkov> pross-au: unlikely [11:58:58] <pross-au> yeah i hate SMT too [11:59:03] <kshishkov> twnqx: looks like it's 100% for me [11:59:15] <twnqx> as long as it's not BGA i'll solder it :P [11:59:42] <jai> twnqx: you still run on agp? :) [11:59:46] <twnqx> no [11:59:52] <twnqx> it was my dad's PC [11:59:56] <jai> k [12:01:32] <twnqx> i've thrown a q6600 that was around in the cas e:P [12:01:44] <twnqx> i'm on i7 myself [12:01:59] <twnqx> and i traded an ipod for my dad's core 2 duo :P [12:02:21] <twnqx> now mom needs a new comp... [12:02:49] <twnqx> i wonder if i should get her an atom... for reading mail, surfing and keeping track of her dvd colelction [12:03:04] <astrange> don't inflict atom on people [12:03:08] <astrange> amd is affordable [12:03:25] <twnqx> but atoms come in cute packaging [12:03:26] <twnqx> :( [12:03:27] <jai> for the listed use cases, atom should be fine right [12:03:33] <twnqx> ell, there's youtube :X [12:04:01] <kshishkov> twnqx: in my case it was shitty packaging, it went to a dump in less than a year of service [12:04:09] <twnqx> :( [12:04:37] <twnqx> i have an acer revo... but only because of the ion. i use it to watch movies only... [12:05:23] * kshishkov is not going to touch Acer again [12:05:31] <twnqx> heh [12:05:34] <thresh> yeah [12:05:39] * thresh wants thinkpad with ion [12:05:43] <twnqx> i modded mine. [12:05:53] <kshishkov> I dumped mine [12:05:57] <roozhou> is it ok to run AMD X2 215 + 780G w/o fans? [12:05:57] <twnqx> replaced the microphone in with an spdif out :P [12:07:00] <twnqx> i still want something in the same booksize form factor with a tegra 250 [12:07:24] <twnqx> friend of mine told me that the tegra 250 devel board is horribly broken, though [12:07:50] <thresh> i thought mru had one [12:08:35] <twnqx> he's working on Volkswagen/Audi next generation entertainment system [12:08:47] <mru> I do have one [12:09:02] <twnqx> lots of bugs? on the board, not the chip? [12:09:35] <mru> haven't played with it much [12:10:00] <twnqx> do you know what's required to get board development specs? [12:10:47] <mru> kernel flashed in fixed location and nda tools needed to replace it [12:11:12] <mru> even boot args hardcoded there [12:11:34] <kshishkov> it's a task for quantum butterfly then [12:29:09] <twnqx> no, i meant... build an own board :X [12:29:39] <twnqx> pinouts, sample components/BOM/schematic/board details, timing details, etc [12:30:49] * twnqx looks at some sample board for interfacing a xilinx spartan 6 fpga to pci express... some interesting details [12:31:14] <twnqx> but i wonder if 300mW for a pci express jitter compensator isn't a bit on the high side [12:37:41] <KotH> prolly not [12:37:52] <KotH> you're dealing with 2.5Gbit/s per lane [12:38:28] <KotH> but, what the heck is a jitter compensator? [12:43:19] <superdump> does anyone in the uk want to buy an i7 off me? i'm not really using it as i'm moving to sweden so it makes little sense to keep it [12:43:29] <ramiro> superdump: when are you moving? [12:43:40] <superdump> probably when i go back in a week or so [12:44:03] <superdump> thought i had an apartment sorted but they decided to sell it instead so looking for another one [12:46:07] <twnqx> KotH: it dies case it retiems the clock lanes [12:46:12] <twnqx> in this case* [12:46:27] <twnqx> to about 5ps precision [12:47:23] <twnqx> hm [12:50:25] <KotH> twnqx: teh clock lanes? [12:50:33] <KotH> twnqx: each clock lane individualy? [12:50:45] <KotH> twnqx: what chip is taht? [12:50:48] <twnqx> there's only one differential clock in PCIe [12:51:04] <twnqx> so, two signals [12:51:11] <KotH> hmm? i thought there is one clock per lane? [12:51:23] <KotH> or am i mistaken? [12:51:37] <twnqx> i'm looking at a x1 design at the moment, so i'm not sure [12:51:44] <twnqx> but i thought there's only one clock [12:52:00] <twnqx> ICS874001 is the chip if you care :P [12:52:43] <twnqx> http://pinouts.ru/Slots/pci_express_pinout.shtml shows only one clock pair, even for more lanes [12:52:47] <KotH> maybe i'm just confusing things [12:54:36] <twnqx> oh, and it's 50ps... [12:55:27] <KotH> blub.. my fault [12:55:35] <KotH> each lane is self-clocked [12:55:47] <KotH> ie clock is recovered from the bitstream [12:56:30] <KotH> and the "jitter compensator" is nothing more than a stable vco with a pll with a 1:1 ratio [12:59:42] <_av500_> &win 4 [12:59:45] <_av500_> oops [13:00:05] <twnqx> adjustable ratio, but yeah [13:00:13] <twnqx> i just wonder if it's necessary [13:05:56] <KotH> no idea [13:06:08] <KotH> i know virtually nothing about pci-e [13:07:20] <twnqx> i want to build an add-in card :] [13:08:11] <twnqx> i just fear that it will require 6 layers minimum [13:09:02] <av500> twnqx: 6 sounds reasonable [13:09:58] <twnqx> i wonder if the "better" PCB software is available as a trial... [13:10:14] <twnqx> eagle is pretty nice, but can't to impedance/length control [13:11:12] <twnqx> and for PCIe i want something with an embedded field solver :X [13:12:17] <KotH> rotfl [13:12:26] <av500> twnqx: getting the impedance from lenght, width, etc should be possible, no? [13:12:27] <KotH> hint: dont even try eagle [13:12:43] <KotH> you'll fail with anything over 2 layers [13:12:50] <KotH> and even two layers is a pain [13:12:51] <twnqx> KotH: i own the pro version without autorouter [13:13:06] <KotH> does the pro version do proper DRC check? [13:13:08] <twnqx> 4 layers is ok, as long as it's two supply layers [13:13:15] <KotH> ^^' [13:13:22] <KotH> forget that with pci-e [13:13:26] <twnqx> yeah :P [13:13:33] <KotH> you'll need impedance matched lines [13:13:36] <twnqx> and 324pin chipscale BGA packages, and ddr2/ddr3 [13:13:44] <KotH> best to have them within two ground planes [13:13:54] <KotH> o_0 [13:14:05] <KotH> ok, we're talking of at least 6 layers [13:14:29] <twnqx> yeah, possibly (likely?) 8 [13:14:44] <KotH> OGD1 is 12 layers iirc [13:14:47] <twnqx> but i have no idea how to fit an fpga + some memory onto a mini-pcie card [13:14:59] <KotH> though it has a 800pin bga [13:14:59] <twnqx> with "normal size" components [13:15:19] <KotH> what's normal size for you? [13:15:29] <twnqx> tqfp, tssop, vqfp... [13:15:31] <funman> hello [13:16:24] <av500> twnqx: forget it [13:16:26] <av500> bga [13:16:50] * KotH thinks the same [13:17:01] <KotH> though 1mm pitch bga should be pretty much painless [13:17:08] <jai> hello to you too funman [13:17:14] <KotH> 0.8mm is a bit more..challenging [13:17:21] <funman> i am looking at issue1503 and i'm wondering who did reverse engineering of wma: i suppose Fabrice Bellard as he's the initial commiter of this code [13:17:28] <twnqx> http://img62.imageshack.us/img62/602/img0312mo.jpg the level shifters (on the pcb) were pain to solder :P [13:18:00] <av500> these are easy [13:18:14] <twnqx> that was my first smd project :X [13:18:14] <av500> given a good solder mask [13:18:28] <av500> good solder mask is the key [13:18:29] <funman> google & wiki.multimedia.cx didn't give me any docs about reverse engineering so i assume the decoder he wrote is the only source of documentation [13:18:31] <twnqx> and the vendor had issues with 0.15mm solder mask width [13:19:08] <av500> ideally, the solder mask leaves holes on the pad where the part more or less fall into place [13:19:14] <KotH> twnqx: 1.27mm pitch ? [13:19:21] <twnqx> 0.4mm pitch [13:19:27] <KotH> o_0 [13:19:43] <KotH> what kind of level shifter are these, to use such an odd pitch? [13:19:56] <av500> 16245 or so I guess [13:20:30] <twnqx> sn74cbt3t16210 [13:20:43] <twnqx> sn74cb3t16210 [13:21:31] <av500> ah, 20bit [13:21:43] <twnqx> yeah [13:24:41] <KotH> those have 0.5mm pitch :) [13:24:49] <twnqx> and regarding eagle's DRC... with the setting i had to use it flooded the space below 0603 components with the ground plane [13:25:08] <KotH> unless you used teh tvsop ;) [13:25:13] <twnqx> i did [13:25:19] <KotH> masochist [13:25:27] <twnqx> no, i was running out of space [13:25:50] <av500> there would have been space for 0.5 [13:26:23] <twnqx> if i traded on other edges, e.g. move the fpga further out (or allow other than 45° angles [13:26:30] <av500> but anyway, as you managed to solder it, you can now call 0.4 HUGE and move on ;) [13:26:42] <KotH> hehe [13:26:55] * KotH would have used a layer more [13:27:09] <twnqx> after doing that... i soldered the 1.27mm components [13:27:14] <twnqx> and they really felt HUGE [13:27:46] <twnqx> KotH: 25pcbs of that were already 200€ [13:27:47] <av500> yeah, feels like pouring concete :) [13:28:09] <twnqx> in 4 layers it would have been more, and i actually need 5-6 [13:28:09] <KotH> twnqx: i know how much pcb's cost [13:28:15] <twnqx> and it's a damn hobby [13:28:18] * KotH does that kind of stuff for a living [13:28:22] <twnqx> oh [13:28:40] <twnqx> i mean, i'd have loved to use 4 layers, would have made power/ground routing easier [13:28:49] <twnqx> especially power. [13:28:53] <KotH> yeah, but it doubles the cost [13:29:04] <twnqx> indeed [13:29:14] <twnqx> and apparently it works (for now) [13:29:36] <twnqx> even though i'd change a LOT [13:29:55] <twnqx> didn't consider that it's almost impossible to find non-pcb versions of the 1.27mm headers.. [13:30:07] <KotH> hint: if you ddr, stick with ddr, dont use ddr3. and use someone else design as an example for both schematic and layout [13:30:34] <twnqx> i'd have to use ddr2 [13:30:46] <KotH> do you have such a datarate? [13:30:48] <twnqx> but yeah, i have xilinx' reference board [13:31:03] <twnqx> no, but spartan 6 features embedded memory controlles - that support ddr2 or 3 [13:31:48] <KotH> they support ddr too, i'd say [13:32:13] <KotH> the lower the clock rate you've to support, the uglier your layout can be [13:32:35] <twnqx> oh you're right [13:32:41] <twnqx> they do. [13:32:59] <KotH> and believe me, having high peak current components like sdram or an fpga is pain enough, no need to make it worse [13:33:32] <twnqx> what do you use, mentor graphics? [13:34:13] <KotH> altium [13:34:16] <twnqx> ah [13:34:30] <KotH> mentor graphics is a lot more expensive, with minimal advantage for us [13:35:13] <twnqx> i wanted to look at altium for the fpga codesign options [13:35:46] <twnqx> so far i use the ugly ISE for that part... but at least that's free [13:36:12] * KotH has never used the co-design stuff [13:36:24] * KotH doesnt think that it can beat hard thinking [13:37:48] <twnqx> i'd like to have some... better options for generating the verilog code (ok, i'd be willing to learn VHDL if necessary) [13:38:01] <twnqx> like, a visual staemachine editor [13:38:59] <KotH> 1) learn vhdl anyways... readability of vhdl is a lot better than verilog [13:39:21] <KotH> 2) use simulink for the state machine design [13:39:22] <BBB___> KotH: I asked phill, no reply yet, will get back to you in a couple of hours [13:39:23] <BBB___> (CMS) [13:39:29] <KotH> BBB___: ack [13:39:29] <BBB___> oh my nick is screwed up [13:39:34] <KotH> BBB___: that too [13:39:36] <KotH> ;) [13:39:48] <kshishkov> BBB___: only left part of your nick is screwed [13:40:03] <kshishkov> can't confuse three underscores with movie name [13:40:18] <av500> B_ig B_uck B_unny [13:42:11] <jai> thats a long tail [13:43:18] <BBB___> the others are taken, it seems [13:44:05] <BBB> shit I keep doing that [13:44:14] <BBB> this irc app has confusing keybindings [13:45:26] <jai> which one? [13:45:38] <jai> just use irssi, and rely on muscle memory [13:45:48] <twnqx> or fix the bindings [13:53:44] <mru> one key to rule them all and in the darkness bind them [13:54:00] * KotH wonders why USB stores the serial number as a UCS-2 string, while only alphanumeric ascii characters are allowed [13:54:14] <elenril> for the lulz? [13:54:29] <_troll_> was microsoft on the design committee? [13:54:38] <elenril> yeah, or that [13:54:46] <KotH> nope, intel [13:54:52] <_troll_> difference? [13:54:58] <KotH> 99% of that stuff is intel only [13:55:01] <KotH> and you can feel it [13:55:24] <KotH> the documentation is basically a listing of tables, with hardly a word describing how they are intended to be used [13:55:41] <KotH> on the other hand, the electrical descriptions are pretty extensive [14:00:14] <BBB> wbs: is it intended that you use av_gettime() in that patch and not ff_ntp_time()? [14:00:43] <wbs> BBB: yes, since the field is public and should be reasonably generic, I chose to store it in av_gettime() scale instead [14:00:43] <_troll_> wtf is "ntp time"? [14:01:02] <BBB> different zero-point [14:01:08] <BBB> it's like fahrenheit vs. celsius [14:01:19] * BBB feels flamewar coming up [14:02:29] * _troll_ goes to read RFC958 [14:03:59] <CIA-92> ffmpeg: benoit * r22544 /trunk/libavcodec/ (w32thread.c pthread.c avcodec.h os2thread.c beosthread.c): [14:04:00] <CIA-92> ffmpeg: Remove avcodec_thread_execute from avcodec.h, and make static functions that [14:04:00] <CIA-92> ffmpeg: need it in *thread.c. [14:08:01] <KotH> _troll_: basically: couting days and seconds of day since apporx 5ky ago [14:08:32] <KotH> er.. 4ky [14:08:37] <_troll_> NTP has epoch 1900-01-01 [14:08:44] <_troll_> you're thinking MJD [14:10:43] <KotH> hmm.. then i'm confusing it [14:10:53] <KotH> there are way to many different time formats anyways ^^' [14:11:15] <_troll_> "NTP timestamps are represented as a 64-bit fixed-point number, in seconds relative to 0000 UT on 1 January 1900." [14:11:38] <_troll_> that's a 32.32-bit fixed-point [14:12:34] <KotH> hmm... [14:12:45] * KotH wonders what UT was used back in 1900 [14:12:58] <BBB> they used handwriting [14:13:30] <_troll_> does RTP use the same format? [14:13:41] <_troll_> or are they just waving acronyms around? [14:13:55] <wbs> they use the same format in RTCP packets, yes [14:14:23] <_troll_> ok, then it makes sense [14:14:46] <_troll_> all that talk about "NTP time" made it sound like yet another time reference [14:14:58] <_troll_> alongside GMT, UTC, UT1, etc, etc [14:16:27] <kshishkov> _troll_: it sounds more like that RTP implementation should include NTP client, web server and mail forwarder [14:19:14] <KotH> _troll_: is ntp time leap second corrected? or is it strict monotonic? [14:19:33] <_troll_> it can signal leap seconds [14:19:38] <_troll_> it doesn't specify a time reference [14:20:10] <_troll_> ntp is nothing but a synchronisation protocol [14:20:35] <_troll_> it doesn't care about the actual reading [14:20:56] <CIA-92> ffmpeg: mstorsjo * r22545 /trunk/libavformat/ (rtsp.c rtsp.h): [14:20:56] <CIA-92> ffmpeg: RTSP: Synchronize the start time of the chained RTP muxers [14:20:56] <CIA-92> ffmpeg: This makes sure that the streams get correctly synchronized when viewed, [14:20:56] <CIA-92> ffmpeg: previously the streams were out of sync by as much time as it took [14:20:56] <CIA-92> ffmpeg: between the initialization of the individual muxers. [14:21:44] <wbs> BBB: thanks for the review - that was the last one of the critical missing features :-) [14:22:18] <BBB> cool :) [14:22:31] <BBB> now we need to get all these rtp depacketizers that I and others wrote a while ago in [14:22:34] <BBB> interested? :) [14:22:51] <wbs> nah, I have a bunch of non-critical additional features written, just ready to be polished up and included ;P [14:23:16] <wbs> after that, maybe :-) [14:23:43] * BBB awaits :) [14:23:55] <wbs> in particular; TCP support for the RTSP muxer, and digest authentication support (for both http and rtsp) [14:24:32] <wbs> the tcp support is quite simple and not too ugly, I think I'll post that one next [14:25:40] <kierank> Does anybody possess an AVCHD spec? [14:26:13] <wbs> digest auth support is a bit more messy though, but principally I think it should be ok... [14:26:13] <_troll_> I'm still struggling to figure out what avchd _is_ [14:26:25] <_troll_> apart from a trademark for a certain line of digital camcorders [14:26:33] <kierank> Blu-ray for home movies [14:27:40] <kierank> but only with h.264 and ac3 or lpcm [14:27:40] <kshishkov> botched container or H.264? [14:28:27] <kierank> It's a normal TS with a 4 byte header like blu-ray [14:28:59] <_troll_> what's in those extra 4 bytes? [14:29:08] <_troll_> the files I've seen played fine after stripping it [14:29:22] <av500> some timestamp, no? [14:29:34] <_troll_> the TS packets already have timestamps [14:29:56] <av500> yes, but looks like whoever uses this TS variant cant be bothered to read TS [14:29:59] <kierank> yes it's 2 copy control bits and a timestamp [14:30:18] <kierank> but i was mainly looking to see if there were more random H.264 restrictions in avchd like blu-ray [14:37:56] <BBB> wbs: uh... [14:38:01] <BBB> wbs: I have code for digest auth [14:38:05] <BBB> wbs: I should port it into ffmpeg [14:38:14] <BBB> I wrote it for http but rtsp is identical [14:38:22] <wbs> yeah, I've got such too, now :-) [14:38:24] <BBB> it doesn't support msg content check [14:38:30] <BBB> oh, darnit :) [14:38:38] <BBB> shall we do a contest who can port it first? i'm 100% sure you'll win [14:38:56] <wbs> I don't think mine supports msg content check either [14:39:04] <BBB> that's because that sucks :) [14:39:10] <wbs> :-) [14:39:42] <wbs> and yes, it works fine in both http and rtsp, but the integration isn't totally clear, so I expect a few comments during the review :-) [14:40:02] <BBB> oh so you ported it already? [14:40:04] <BBB> cool [14:40:07] <BBB> saves me having to do it [14:40:17] <wbs> the need arose from rtsp (since password protection is much more common when sending stuff than when watching it) - cleartext password is so 1980s [14:40:27] <BBB> well yeah [14:40:31] <BBB> but someone gave us a patch [14:42:46] <wbs> anyway, I'll post it sometimes soonish [14:43:41] <BBB> cool [15:00:39] <merbzt> janneg: I think I have a core 2 duo free for some rendering work if it is easy to set up the rendering jobs [15:00:52] <merbzt> and how much memory is needed [15:02:45] <av500> >4GB [15:02:47] <av500> 6 or ( [15:02:48] <av500> 6 or 8 [15:04:03] <BBB> KotH: drupal please [15:06:25] <BBB> (and thanks!) [15:09:01] <merbzt> av500: >4GB to render the pictures ? [15:09:16] <merbzt> wont 4 do it [15:09:30] <merbzt> that's the max I can use in the box [15:14:12] <janneg> merbzt: I would guess 50% of the frames get OOM killed with 4G + 500M swap [15:14:59] <twnqx> Oo [15:15:06] <twnqx> what...are you rendering? [15:15:20] <mru> bunnies [15:15:23] <janneg> Big Buck Bunny in 2700x1440 [15:15:35] <merbzt> janneg: :/ [15:17:18] <twnqx> ok, if it was something else i'd have chipped in :P [15:17:38] <janneg> merbzt: but as long as there are frames which render with 4G it's useful. the script which creates the job files takes existing pictures into account [15:18:20] <merbzt> hmmm, ok, I'll see if I can get the box working with 4 gig then [15:18:47] <janneg> i.e. it makes sense to run a job file with 4G machine, regenerate the job and render the other frames on a machine with more RAM [15:19:20] <janneg> mru tried that but his quad core died [15:19:42] <mru> I'll try to revive it [15:20:38] <janneg> merbzt: instructions are here http://www.jannau.net/bbb_videowall/, ask if something is not clear [15:21:07] <merbzt> ok, thnx [15:22:31] <BBB> merbzt: did you talk to that guy that wanted to RE WVP2? [15:22:59] <merbzt> yes [15:23:18] <BBB> what happened to the wiki page? [15:23:27] <BBB> there used to be a wiki page that you showed me, I can't find it anymore :) [15:23:33] <BBB> (how to get started with RE) [15:23:49] <merbzt> I have no idea what you talk about [15:24:23] <merbzt> elaborate [15:24:34] <BBB> I remember there being a page on how to load self-written code at runtime into a binary dll [15:24:43] <BBB> to replace functions one-by-one with self-written instructions [15:25:08] <BBB> it was like a simple howto for beginners [15:25:22] <merbzt> well I don't remember a wiki page about it [15:25:40] <merbzt> dig ein your logs [15:25:58] <jai> code injection? [15:26:36] <BBB> hm, ok.. [15:26:39] <BBB> jai: yes [15:27:27] <janneg> skype has submitted silk to ietf: [15:27:31] <janneg> http://tools.ietf.org/html/draft-vos-silk-01 [15:28:36] <BBB> that's useful [15:28:39] <janneg> and they have source code under a gpl incompatible license [15:28:55] <janneg> https://developer.skype.com/silk [15:29:21] <av500> where is the fun in that :) [15:29:51] <KotH> BBB: could you please send a mail to -legal, then it's proberly archived :) [15:29:58] <mru> whoever takes up that job offer gets access to all the secrets... [15:30:14] <KotH> BBB: i'll install it as soon as i have some free time (prolly this weekend) [15:30:15] <merbzt> janneg: do you know the owl is rendered incorrectly ? [15:30:22] <av500> merbzt: yes [15:31:16] <av500> janneg: oops, I read "compatible" :) [15:31:31] <KotH> merbzt: the source files are horribly broken [15:33:02] <janneg> av500: finding bugs in the spec/skype's implementation [15:33:39] <merbzt> so broken it's not possible to rerender the movie ? [15:33:49] <BBB> KotH: thanks [15:33:57] <andoma> seems libnut was around already in 1993: http://github.com/alandipert/ncsa-mosaic/tree/master/libnut/ [15:34:15] <janneg> KotH: have you seen that blender occasionally tries to open a sound device [15:35:28] <janneg> merbzt: yes, I haven't filled a bug yet. but if BBB was gpl licensed I would say they failed to publish the corrosponding sources [15:35:32] <KotH> janneg: nope.. i dont care... there is no sound device :) [15:37:43] <janneg> neither do I care, but it's strange. why would blender need sound device for rendering? [15:38:10] <KotH> offloading of some calculations? :) [15:38:27] <kshishkov> rendering 3D sound as well? [15:38:36] <janneg> av500: the fun is finding bugs in the spec [15:39:29] <av500> janneg: outputting "I need more memoryyyyy" over the sound dev? [15:40:40] <kshishkov> janneg: reminds me of ideal patent description formula - "describe everything clearly without giving away a way to implement it" [15:41:13] <av500> kshishkov: then nobody can infringe.... [15:41:20] <pengvado> clearly? [15:41:51] <KotH> kshishkov: the ideal patent is as broad as possible, so that as many technologies are covered by it [15:42:00] <KotH> kshishkov: hence, detailed descriptions are contraproductive [15:42:46] <kshishkov> but it makes it easier to be disputed [15:43:07] <DonDiego> hi [15:43:14] <DonDiego> Yuvi: i stumbled across more theora testsuite samples [15:43:17] <kshishkov> hej [15:43:20] <DonDiego> http://wiki.xiph.org/TheoraTestsuite [15:43:48] <DonDiego> i added the missing ones to our samples repo: [15:43:50] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/ [15:44:01] <DonDiego> new samples: [15:44:03] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/ducks_take_off_4… [15:44:15] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/offset_test.ogv [15:44:21] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/sign_irene_cif-3… [15:44:28] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/stockholm-vfr.ogg [15:44:46] <DonDiego> i haven't tested the samples yet [15:44:49] <av500> looks like the duck need to be better encoded with wavelets.... [15:45:19] <DonDiego> av500: can you play the samples? [15:45:28] <av500> yes, my webbrowser plays them [15:45:47] <kshishkov> av500: don't mention that d-word. Don't you know that On2 was originally called D*ck Corporation back in VP3 times? [15:47:48] <av500> duck duck duck [15:47:52] <kshishkov> ni! [15:48:54] <pJok> thee kshishkov who formerly said ni! [15:49:08] * mru demands a shrubbery [15:49:35] <kshishkov> pJok: yes, I've heard that since 1967 you say "du" instead of "ni" [15:49:54] <mru> no wonder their codecs are quack [15:50:06] <kshishkov> mru: cut the highest tree in the forest with this herring first [16:02:46] <DonDiego> bbl, cu [16:16:40] <CIA-92> ffmpeg: mstorsjo * r22546 /trunk/libavformat/rtsp.c: Reindent [16:32:06] <CIA-92> ffmpeg: mstorsjo * r22547 /trunk/libavformat/ (rtsp.c rtsp.h): Make rtsp_skip_packet non-static, add ff prefix [16:37:10] <CIA-92> ffmpeg: mstorsjo * r22548 /trunk/libavformat/rtspenc.c: [16:37:10] <CIA-92> ffmpeg: Don't let ff_rtsp_read_reply skip interleaved RTP/TCP packets in rtsp_write_packet. [16:37:10] <CIA-92> ffmpeg: Skip interleaved packets manually and recheck if there's more to be read. [16:37:44] <CIA-92> ffmpeg: mstorsjo * r22549 /trunk/libavformat/rtspenc.c: Reindent [16:37:46] <CIA-92> ffmpeg: michael * r22550 /trunk/ (7 files in 6 dirs): [16:37:46] <CIA-92> ffmpeg: use mpeg2 quantization bias for mjpeg. [16:37:46] <CIA-92> ffmpeg: this seems to improve RD performance. [18:23:24] <BBB> MrNaz: ping [19:04:43] <CIA-92> ffmpeg: jai_menon * r22551 /trunk/libavformat/matroskaenc.c: cosmetics : Print newline after error message. [19:11:51] <jai> great, i can commit again :) [19:26:13] <CIA-92> ffmpeg: mru * r22552 /trunk/ (353 files in 4 dirs): (log message trimmed) [19:26:13] <CIA-92> ffmpeg: Add FATE tests [19:26:13] <CIA-92> ffmpeg: This adds a "fate" make target which runs the full FATE test suite. [19:26:13] <CIA-92> ffmpeg: Individual tests can be run with "make fate-$testname". [19:26:13] <CIA-92> ffmpeg: The location of the FATE test samples must be specified with the [19:26:14] <CIA-92> ffmpeg: --samples=PATH option to configure. [19:26:15] <CIA-92> ffmpeg: The tests/fate-update.sh script regenerates the references files and [19:29:39] <mru> do I get the prize for most files in a single commit? [19:30:15] <kshishkov> yes if you manage to pry it from Diego's hands [19:30:52] * av500 goes off to buy new hdd.... [19:31:53] <jai> mru: any idea by how much does this increases the repo size ? [19:32:10] <jai> -s [19:32:39] <mru> git, not noticably [19:34:10] <mru> the samples are not checked in for obvious reasons [19:34:27] <av500> they could not be zipped? :) [19:34:56] <kshishkov> they are at MPHQ already [19:35:26] <mru> the reference files are 800k total [19:35:35] <mru> that's nothing compared to the tens of MB of code [19:36:22] <drv> my local SVN checkout du on ext3 grew about 4 MB, and that includes some other commits [19:36:34] <mru> that's svn power for you [19:36:52] <mru> new slogan for them: svn makes everything look big [19:37:07] <kshishkov> heh [19:37:07] <drv> warning: objects in svn may be larger than they appear [19:37:16] <mru> drv: lol [19:37:26] <kshishkov> iceberg for SVN logo! [19:37:34] <mru> drv: people who haven't been to the US may not understand that one [19:37:58] <kshishkov> is that about rear view mirror warning? [19:38:00] <drv> hehe, true, i guess that's not on mirrors everywhere [19:38:11] <mru> haven't seen it in europe [19:38:24] <drv> actually i don't even know if it's on my car, i should go check sometime [19:38:25] <kshishkov> less idiots? [19:38:34] <drv> less idiots with access to lawyers perhaps [19:38:35] <mru> well, at least it's not known to the government of the state of california to contain lead [19:39:05] <ramiro> svn export from 22551: 40968, 22552: 44808 [19:39:22] <ramiro> in bz2, from 6416 to 6848 [19:39:27] <ohsix> haha :( https://bugzilla.gnome.org/show_bug.cgi?id=612773 [19:39:36] <mru> ramiro: does that include filesystem overhead? [19:39:45] <ramiro> mru: using du, so yes. [19:39:52] <mru> 350 tiny files might take some space [19:39:56] <jai> ramiro: thx :) [19:40:16] <drv> i should try moving my /home to ext4 sometime [19:40:37] <pJok> drv, isn't it just a matter of mounting it as ext4? [19:40:52] <mru> no [19:40:57] <mru> ext4 is not compatible at all [19:40:58] <drv> well, you need to run a fsck to get it to enable the new features i think [19:40:59] <jai> i wanted to try out btrfs for /tmp [19:41:18] * mru uses tmpfs for /tmp [19:42:00] <kshishkov> fat12 anyone? [19:42:21] <jai> mru: low ram :| [19:42:33] <ramiro> jai: buy some more, it's getting cheap. [19:42:44] <jai> kshishkov: have some floppies here i think [19:42:51] <kshishkov> jai: how low ram? [19:42:58] <jai> kshishkov: 512mb [19:43:07] <jai> it isnt _that_ low [19:43:11] <kshishkov> huh? you call that low? [19:43:15] <mru> I do [19:43:18] <jai> i knew you would say that [19:43:20] <mru> anything below 4G is low [19:43:20] <jai> :) [19:43:23] <BBB> how do I make the build non-quiet? [19:43:26] <BBB> I want to see a gcc command [19:43:28] <mru> make V=1 [19:43:28] <drv> make V=1 [19:43:29] <jai> BBB: V=2 [19:43:30] <BBB> thanks [19:43:32] <jai> hmm [19:43:44] <jai> so what happens with V=2? [19:43:44] <mru> V=2 makes make test even noisier [19:43:48] <drv> jai's make is one louder ;) [19:43:56] <mru> make V=11 [19:43:57] <jai> drv: linear scale i see :) [19:44:07] <kshishkov> only because of loud HDD [19:46:53] <CIA-92> ffmpeg: michael * r22553 /trunk/ffmpeg.c: Allow mpeg style yuv in jpeg when strict standard compliance is small enough. [20:42:04] <gmaxwell> Yo. I don't know if yuvi has replaced the ffmpeg oggmux in some branch of his yet, but the code in your current git is completely busted for packets which are a multiple of 65025 bytes. It fails to terminate the packets... only creating a segment free continuation page. [20:42:19] <gmaxwell> I'll happily send a patch if this code hasn't been trashed yet, but I sure hope it has. [20:42:36] <Dark_Shikari> 65025 bytes? that must be an odd bug [20:42:50] <gmaxwell> This is an example file produced by making libtheora always output that size: http://myrandomnode.dyndns.org:8080/~gmaxwell/fffail.ogv [20:43:01] <Dark_Shikari> I don't think Yuvi has replaced it yet, but I may not have been watching carefully enough [20:43:17] <Dark_Shikari> he seems to mostly be fixing security holes and optimizing the theora decoder [20:43:21] <Dark_Shikari> (which is now faster than libtheora, yay) [20:43:27] <gmaxwell> The issue is the if(size) check and page_segments computation in ogg_write_page. It's a trivial fix— someone went out of their way to do it wrong here. :) [20:44:14] <gmaxwell> In any case, yuvi is usually around in #theora, so I presume I'll hear from him if he wants a patch. [20:44:35] <gmaxwell> TTYL! [20:45:59] <gmaxwell> Oh, and thats fantastic news that the decoder is now fast. [20:47:56] <Compn> current git you say... [21:28:05] <CIA-92> ffmpeg: michael * r22554 /trunk/libavcodec/ (mpegvideo.h mpegvideo_enc.c mpeg12decdata.h mpegvideo.c): Support intra_dc_precision>8 in jpeg [21:53:29] <BBB> merbzt: why does the atrac1 decoder clip to 32700/32768? and will you kill me if I chagne that to -1/1? [21:54:19] <mru> it will kill performance for sure [21:54:34] <mru> and you can't just go and change the clip [21:54:38] <mru> you have to change the scaling too [21:54:44] * mru states the obvious [21:56:38] <BBB> it clips to -0.998 [21:56:42] <BBB> I want it to clip to -1 [21:56:45] <BBB> I don't see a problem [21:57:06] <BBB> I'm just asking if that's what the binary does, or something else [21:57:36] <BBB> scaling doesn't change [21:58:23] <pengvado> even if that's what the binary does (or the standard for formats that have a standard), it's almost certainly the wrong thing to do. if the output format were float, then you shouldn't clip at all. [21:59:49] <BBB> hmm.... [21:59:56] * BBB re-reads MN msg [22:00:12] <BBB> oh right, he actually says that [22:01:54] <mru> I somehow read that as clipping to ~32k, not ~1 [22:01:58] <mru> forget what I said [22:14:01] <BBB> pengvado: you're correct, I'm removing it as we spea [22:14:03] <BBB> +k [22:14:43] <mru> here's a good example of why gcc intrinsics suck: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43118 [22:33:41] <ramiro> BBB: you will apply it 3 days ago? =) [22:33:50] <BBB> did I really say that? [22:33:58] <BBB> I'll just assume nobody read that :) [22:34:08] <ramiro> you said "+/- 3 days" [22:34:12] <ramiro> it could be -3 days... [22:35:47] <BBB> oh [22:35:51] <BBB> well that's not so bad [22:36:02] <BBB> +/-, in dutch, means "approx." :) [22:37:37] <ramiro> hmm, we usually use ~ for approx. [22:37:58] <thresh> we use '+/-' like that too [22:38:03] <CIA-92> ffmpeg: aurel * r22555 /trunk/libavformat/Makefile: matroskadec: fix missing dependency [22:38:42] <hyc> I'm surprised folks are still playing with atrac1 [22:39:33] <hyc> I worked on reversing that codec back in 1998-99 [22:40:13] <hyc> still have my SCSI MD-Data drive with hacked firmware to read audio tracks [22:42:31] <BBB> hyc: ? [22:42:50] <BBB> hyc: it's a minor patch to the decoder, I'm not actively developing it [22:42:59] <hyc> ah [22:44:15] * BBB goes gome [22:50:34] <CIA-92> ffmpeg: michael * r22556 /trunk/libavcodec/ (mpegvideo.h mpegvideo_enc.c mpeg12.c mpegvideo.c): Add ff_ prefix for mpeg2_dc_scale_table. [22:55:13] <CIA-92> ffmpeg: michael * r22557 /trunk/libavformat/ (aviobuf.c avio.c avio.h): [22:55:13] <CIA-92> ffmpeg: Add AVSEEK_FORCE flag to indicate that the code should attempt to seek [22:55:13] <CIA-92> ffmpeg: by any means. [23:01:43] <CIA-92> ffmpeg: mru * r22558 /trunk/libavcodec/h264.h: [23:01:43] <CIA-92> ffmpeg: H264: fix signed overflow in constant multiplication [23:01:43] <CIA-92> ffmpeg: This fixes libavcodec/h264.h:1100: warning: integer overflow in expression [23:05:06] <CIA-92> ffmpeg: bcoudurier * r22559 /trunk/libavformat/oggenc.c: Correctly write last 0 lacing value when packet size is multiple of 255, patch by Greg Maxwell, gmaxwell at gmail dot com [23:11:52] <CIA-92> ffmpeg: bcoudurier * r22560 /trunk/libavcodec/Makefile: mpegts muxer now needs mpeg4audio code like adts muxer [23:14:55] <CIA-92> ffmpeg: aurel * r22561 /trunk/libavformat/ (mpegts.c utils.c internal.h): [23:14:55] <CIA-92> ffmpeg: rename av_program_add_stream_index to ff_program_add_stream_index [23:14:55] <CIA-92> ffmpeg: it is an internal function, not part of public API [23:16:22] <CIA-92> ffmpeg: aurel * r22562 /trunk/libavformat/ (seek.c utils.c internal.h): [23:16:22] <CIA-92> ffmpeg: rename av_read_frame_flush to ff_read_frame_flush [23:16:22] <CIA-92> ffmpeg: it is an internal function, not part of public API [23:33:29] <CIA-92> ffmpeg: daniel * r22563 /trunk/tools/patcheck: patcheck: Escape parentheses in grep calls [23:41:41] <CIA-92> ffmpeg: bcoudurier * r22564 /trunk/libavcodec/Makefile: 100L, revert r22560, already present [23:50:36] <mika_video> Why are the existing fields in essential structs of libavcodec and libavformat sometimes reordered ? [23:55:34] <mru> ??? [23:55:49] <Dark_Shikari> mru: he hasn't made any sense in any channel for days... [23:56:52] <mika_video> there was binary incompatible changes between versions version 52.0.0, and version 52.52.55.0 of avcodec [23:57:23] <mika_video> the codex_type field of struct AVCodecContext has moved from offset 0xE0 to offset 0xdc [23:59:27] <mika_video> the newer of those two should be 52.55.0 , sorry the typo.

1 0

IRC log for 2010-03-14
by irc＠mansr.com 15 Mar '10

15 Mar '10

[00:43:18] <CIA-92> ffmpeg: michael * r22517 /trunk/libavcodec/error_resilience.c: Ensure that the deblock filter accesses the correct MVs for h264. [01:33:32] <CIA-92> ffmpeg: stefano * r22518 /trunk/libavutil/error.h: Lexically sort the error code definitions. [01:33:33] <CIA-92> ffmpeg: stefano * r22519 /trunk/libavutil/error.h: [01:33:34] <CIA-92> ffmpeg: Mark AVERROR_ENOENT for deletion at the next libavutil major bump. [01:33:34] <CIA-92> ffmpeg: The symbol is currently unused, AVERROR(ENOENT) must be used instead. [01:53:19] <CIA-92> ffmpeg: michael * r22520 /trunk/ (3 files in 3 dirs): Make sure all mvs of a mb are set in the error concealment code. [04:06:31] <Dark_Shikari> static (*func)( int16_t *, uint32_t ) x264_cache_mv_func_table[12] [04:06:33] <Dark_Shikari> why doesn't this work? [04:06:36] <Dark_Shikari> (an array of function pointers) [04:18:01] <mru> static void (*func[12])(int, ...); [04:19:37] <Dark_Shikari> windows file locking is blegh [04:19:46] <Dark_Shikari> lol, accidentally hit "up" in the wrong window [04:19:47] <Dark_Shikari> I hate that [04:20:05] <Dark_Shikari> mru: works great. thanks [10:35:17] <astrange> can i get git svn dcommit to work from a git.ffmpeg.org clone? [10:35:38] <kshishkov> try it [10:35:42] <KotH> hmm.. i think so [10:35:49] <KotH> at least mru uses git to commit to svn [10:35:53] <KotH> dunno how though [10:36:26] * kshishkov prefers direct approach with minimum intermediate abstraction levels [10:37:20] <astrange> copying and applying multiple patches seems more error prone than one dcommit [10:38:06] * KotH preferes not to commit anything [10:38:11] <KotH> less mistakes this way ;) [10:38:47] <kshishkov> yes, Russian proverb is "one who does not do anything does not do mistakes either" [10:41:49] * KotH notes that he could be a good russian, if he'd drink vodka [10:45:11] <kshishkov> indeed, not that it's something to be proud about though IMO [10:46:18] <Yuvi> pretty sure it's impossible to set up git-svn with git.ffmpeg.org's repo [10:47:07] <Yuvi> mru uses a different repo that has the right urls in commit messages, I forget how I set it up to get dcommit to work from that [13:39:02] <CIA-92> ffmpeg: reimar * r22521 /trunk/libavformat/avidec.c: [13:39:02] <CIA-92> ffmpeg: Avoid creating tiny (possibly only 64 bytes large) audio packets resulting in [13:39:02] <CIA-92> ffmpeg: huge processing and memory usage overhead for avi files with raw PCM audio. [17:46:31] <ramiro> any tips I should follow when REing a DLL written in c++? like in how do I reconstruct a proper class? [17:47:46] <mru> it's usually pretty obvious [17:47:52] <mru> which compiler? [17:48:01] <ramiro> msvc++ [17:48:08] <ramiro> or so that's what IDA says [17:48:26] <mru> ecx contains the this pointer [17:48:42] <mru> first field it points to is the vtable for the class [17:48:56] <mru> data fields follow [17:49:41] <mru> if you find a constructor you can usualy figure out at least an outline of the class [17:51:58] <kshishkov> and demangling names also gives a lot of useful information [17:52:40] <ramiro> the dll has very few symbols [17:52:54] <kshishkov> what's its name? [17:55:23] <kshishkov> in most cases I don't even bother about class structure [17:56:48] <kshishkov> RV for example had nothing very useful in constructors [17:58:24] <kshishkov> mru: found an example of very good thinking - my netbook had Ethernet NIC MAC printed on sticker. The catch is that sticker is placed on HDD connector so I found it only after full disassembly [17:58:55] <mru> nice [17:59:18] <kshishkov> and there was one case where I'd like to know it without powering that netbook [18:00:20] <ramiro> does it void warranty as well? [18:00:28] <kshishkov> screw warranty [18:00:36] <ramiro> kind of like dogbert's help desk... the serial number is conveniently placed inside the unit. [18:01:05] <kshishkov> I had to took it to warranty repair because of HDD read failure - they did nothing except disconnecting touchpad [18:01:33] <kshishkov> and now it just does not take DC input [18:41:52] <mfg> Is there something wrong with my resubmission of the probe loop patch? Last time it was checked it shortly after the review. [18:42:17] <kshishkov> better ping [18:42:31] <mfg> ? [18:42:59] <kshishkov> if there was no reaction on it for a week you just send reminder [18:43:09] <mfg> i did. there was no response to that either. [18:44:17] <kshishkov> try again then, there should be some response after second or third ping for sure [18:44:46] <mfg> ok [18:49:46] <saste> mfg: I'll reapply it again later [18:50:01] <saste> then we'll see if it will break fate again ;-) [18:50:08] <mfg> lol [18:50:19] <mfg> I wish I could run the full regression at home [18:50:33] <mfg> at least on my native arch [18:50:46] <kshishkov> mfg: yes, complaining on IRC also helps sometimes [18:51:12] <mfg> hey! I wasn't complaining ;) I was "reminding" [18:51:21] <mfg> :) [18:51:33] <saste> I thought about the same... maybe the fate guys can say if that's possible [18:51:41] <saste> I didn't played much with fate yet... [18:54:08] <twnqx> 2-3 days [18:54:40] <elenril> about complaining on irc, somebody can apply a patch for me? ;) [18:55:04] <kshishkov> it's not December yet ;) [18:55:08] <mfg> lol [18:56:27] <elenril> that's it, no delicious cake for kshishkov [18:56:44] <kshishkov> it''s alie anyway [18:57:11] <elenril> 'cake is a lie' is a lie [18:57:42] <kshishkov> I'm glad [18:58:02] <kshishkov> and I can manage without cake anyway [18:58:43] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/SourGrapesTropes [19:19:39] <mru> BBB: about those plots you were doing [19:19:48] <BBB> hi, sorry I left [19:19:54] <mru> I was asking you to do a single plot of in/out [19:20:06] <BBB> in the same graph? [19:20:06] <mru> err, out/in [19:20:13] <BBB> or out divided-by in [19:20:15] <mru> yes [19:20:17] <mru> divide [19:20:24] <mru> and log(out/in) too [19:20:25] <BBB> frequencies [19:20:32] <BBB> right? [19:20:35] <mru> frequency on horizontal axis, yes [19:20:50] <mru> that's how a frequency response graph is usually done [19:21:26] * BBB goes check how to do that [19:26:07] <BBB> working on it [19:26:11] <CIA-92> ffmpeg: mru * r22522 /trunk/ (12 files in 3 dirs): [19:26:11] <CIA-92> ffmpeg: Separate DWT from snow and dsputil [19:26:11] <CIA-92> ffmpeg: This moves the DWT functions from snow.c and dsputil.c to a file of [19:26:11] <CIA-92> ffmpeg: their own. A new struct, DWTContext, holds the function pointers [19:26:11] <CIA-92> ffmpeg: previously part of DSPContext. [19:26:12] <CIA-92> ffmpeg: mru * r22523 /trunk/libavcodec/ (dwt.h snow.c dwt.c): Add ff_ prefix to dwt functions [19:28:48] <CIA-92> ffmpeg: reimar * r22524 /trunk/libavcodec/ (tableprint.c tableprint.h): Add some more table-printing functions needed for future patches. [19:29:57] <BBB> you want after/before, not after-before? [19:30:06] <mru> yes [19:30:08] <BBB> 25/15 and -25/-15 will both give the same number [19:30:09] <BBB> not very informative [19:30:24] <mru> that's exactly what you want [19:30:42] <mru> it's a scaling [19:31:17] <CIA-92> ffmpeg: reimar * r22525 /trunk/libavcodec/ (qdm2.c qdm2_tablegen.c qdm2_tablegen.h Makefile): Allow hard-coding several QDM2 tables (about 32 kB size). [19:31:34] <BBB> http://people.gnome.org/~rbultje/beforeafter.png [19:31:46] <BBB> you shouldn't need a log(), but let me know if you want it anyway [19:32:12] <BBB> unless you meant log(x-axis) [19:33:54] <BBB> my impression is that much more than a bandpassfilter, it's simply a filter that strengthens the high-amplitude?dB output and weakens the low-dB-output [19:34:09] <BBB> we already concluded it wasn't a simple bandpassfilter, I think [19:35:22] <mru> uh, what's that a plot of? [19:37:29] <BBB> output frequencies / input frequencies [19:37:33] <BBB> X-axis is frequencies [19:37:38] <BBB> output is dBout/dBin [19:37:40] <BBB> Y-axis [19:38:30] <BBB> I forgot to label the X-axis I guess [19:42:02] <mru> that's not what I said [19:42:11] <mru> you plotted log(out)/log(in) [19:42:24] <mru> I want out/in and log(out/in) [19:42:36] <mru> the latter is of course log(out)-log(in) [19:43:30] <mru> http://en.wikipedia.org/wiki/Bode_plot [19:43:46] <BBB> oh [19:43:50] <BBB> oops [19:43:51] <BBB> let me try again [19:43:57] <BBB> I didn't know input was log() already [19:44:18] <mru> dB means 10*log10(x) [19:45:05] <peloverde> or 20*log10 dependi g on conext [19:45:11] * mru thinks BBB needs to study some signals and systems [19:45:19] <mru> peloverde: yes, power vs energy [19:48:02] <BBB> sorry :( [19:48:22] <BBB> 1.93654E-26 4.54841E-20 4.25762E-07 -6.370833 [19:48:24] <BBB> oops [19:48:29] <BBB> http://people.gnome.org/~rbultje/logbeforeafter.png [19:48:31] <BBB> wrong copypaste [19:49:10] <CIA-92> ffmpeg: mru * r22526 /trunk/ (Makefile common.mak): Fix brief make output for generated tables [19:49:17] <mru> now you can clearly see some lowpass characteristics [19:49:21] <mru> but it's quite erratic [19:50:13] <BBB> if you look here: http://people.gnome.org/~rbultje/lowpassfilter.png [19:50:43] <BBB> you see that the filter ("removing") strength correlates with dBs [19:51:05] <BBB> so the filter simply weakens weak frequencies [19:51:58] <mru> why can't you get that resolution in the other plot? [19:52:08] <mru> it had only a couple dozen data points [19:52:54] <BBB> uh, audacity pretties up the graph, that's all [19:53:08] <BBB> the excel graph is with the data given to me by audacity [19:53:40] <mru> audacity is crap [19:54:02] <mru> are you saying it invents hundreds of data points? [19:54:16] <BBB> ? [19:54:25] <BBB> which one has more data points according to you? [19:54:35] <mru> the double-screenshot one [19:54:46] <BBB> it's the same data, interpolated using a hanning window [19:54:52] <BBB> see the button on the bototm left [19:55:00] <BBB> if you change it, the shape of the data points changes [19:55:05] <BBB> I can make it rectangular [19:55:10] <BBB> then it looks equally crappy [19:55:48] <BBB> or maybe it actually does a wider bit radix, and the 512 setting only applies to the exported data [19:56:13] <BBB> no, 512 is the input [19:57:35] <mru> you can't have 7kHz components in 512 samples [19:57:42] <mru> err [19:57:55] <BBB> 1<<bit_radix=512 [19:57:59] <mru> what exactly is the x axis there anyway? [19:58:11] <mru> is that taking sampling rate into accout? [19:58:14] <mru> +n [19:59:06] <ramiro> what the hell is a _purecall? [19:59:18] <BBB> sorry, new one with actual frequencies, I again didn't label the X-axis [19:59:25] <mru> ramiro: one the many calling conventions on mswindows [20:00:43] <CIA-92> ffmpeg: reimar * r22527 /trunk/libavcodec/ (aac.c cbrt_tablegen.c Makefile cbrt_tablegen.h): Allow hard-coding of the 32kB cubic-root table for AAC. [20:00:48] <Dark_Shikari> purecall? wtf is that [20:01:08] <mru> probably something C++ related [20:01:29] <ramiro> I get: .rdata:10108970 off_10108970 dd offset _purecall [20:01:47] <ramiro> on that offset there is: .text:100E8D7C jmp ds:__imp__purecall [20:02:10] <ramiro> which is an extrn [20:02:15] <mru> ah, that's what traps calls to virtual functions with no implementation [20:02:27] <mru> and throws a nasty exception and dies [20:03:35] <ramiro> ah, I remember seeing something like that back when I used some c++... [20:05:28] <mru> you learn a lot through RE work [20:11:10] <ramiro> __userpurge? [20:12:41] * BBB has to leave again [20:13:04] <BBB> thanks for the help so far :) sorry I'm a little absent today/yesterday [21:17:19] <CIA-92> ffmpeg: stefano * r22528 /trunk/libavutil/error.h: [21:17:19] <CIA-92> ffmpeg: Change the definition of AVERROR_NUMEXPECTED at the next libavutil [21:17:19] <CIA-92> ffmpeg: major bump, using an FFmpeg specific error code rather than EDOM, [21:17:19] <CIA-92> ffmpeg: which has a quite different semantics. [22:26:23] <CIA-92> ffmpeg: mru * r22529 /trunk/libavutil/error.h: Add missing includes to libavutil/error.h [22:26:23] <CIA-92> ffmpeg: mru * r22530 /trunk/libavutil/error.h: [22:26:23] <CIA-92> ffmpeg: error.h: test EDOM instead of EINVAL [22:26:23] <CIA-92> ffmpeg: C99 doesn't require EINVAL, only EDOM, EILSEQ, and ERANGE. [22:30:03] <CIA-92> ffmpeg: mru * r22531 /trunk/libavcodec/dwt.c: [22:30:03] <CIA-92> ffmpeg: DWT: x86 init should depend on HAVE_MMX [22:30:03] <CIA-92> ffmpeg: The init function is only compiled if MMX is enabled, the call [22:30:03] <CIA-92> ffmpeg: must use the same condition. [22:41:17] <CIA-92> ffmpeg: stefano * r22532 /trunk/libavformat/ (utils.c internal.h): (log message trimmed) [22:41:17] <CIA-92> ffmpeg: Move the probe loop from av_open_input_file() into its own method [22:41:17] <CIA-92> ffmpeg: av_probe_input_buffer() so that it can be reused. Here are a few [22:41:17] <CIA-92> ffmpeg: differences to the original way things were probed: [22:41:17] <CIA-92> ffmpeg: - maximum probe buffer size can be specified as a parameter. [22:41:18] <CIA-92> ffmpeg: - offset within the stream to probe from can be specified as a parameter. [22:41:19] <CIA-92> ffmpeg: - instead of seeking back to the start each time a probe fails, stream [23:53:38] <CIA-92> ffmpeg: cehoyos * r22533 /trunk/libavcodec/vdpau.c: Cosmetics: Fix a comment.

1 0

IRC log for 2010-03-13
by irc＠mansr.com 14 Mar '10

14 Mar '10

[01:49:43] <Dark_Shikari> hmm, is there a decent channel for kernel-related stuff? [01:49:48] <Dark_Shikari> though if anyone knows the answers to these it'd be nice [01:50:03] <Dark_Shikari> 1) Does the linux kernel have a prefetch_this_file feature? I don't think so, but it might have been added when I wasn't looking. [01:50:08] <ohsix> theres ##kernel but none of the major committers are there [01:50:21] <Dark_Shikari> 2) If I mmap a file and vmadvise every page in it, does that do 1) ? [01:50:23] <ohsix> you use mmap and madvise to do that [01:50:25] <Dark_Shikari> lol [01:50:29] <Dark_Shikari> So it works? [01:50:42] <ohsix> its a hint, but thats what it does if it can [01:50:54] <Dark_Shikari> do we know how much it listens? [01:51:18] <ohsix> the metaphorical we? i dont know, i personally dont know though, you can look in mm and see what it does [01:51:30] <astrange> posix_fadvise() [01:51:33] <ohsix> does this look weird to you btw http://paste.ubuntu.com/394242/ [01:51:47] <Dark_Shikari> astrange: does it actually work? [01:52:02] <astrange> probably, i just did 'apropos advise' [01:52:06] <astrange> there's readahead(2) as well [01:52:13] <Dark_Shikari> basically the idea is, suppose we have grep [01:52:23] <Dark_Shikari> grep is slow because the filesystem cannot reorder grep's requests [01:52:36] <Dark_Shikari> if we can tell the filesystem what grep is going to do over the next, say, 5-10 seconds [01:52:39] <Dark_Shikari> it can reorder them [01:52:57] <ohsix> why would it reorder a linear search [01:53:04] <Dark_Shikari> ohsix: because disks are disks [01:53:17] <Dark_Shikari> filesystems _love_ reordering reads [01:53:24] <ohsix> but its not the only io going on [01:53:34] <Dark_Shikari> still doesn't matter [01:53:46] <Dark_Shikari> grep will not request the next chunk until it's done with the current chunk [01:53:50] <ohsix> it doesn't preclude reordering, it happens, but not from greps perspective [01:54:00] <Dark_Shikari> How can the filesystem reorder only one read at a time? [01:54:16] <ohsix> it will chew through everything it has faster than it'll get it off the disk, its not likely it will speed it up much [01:54:30] <Dark_Shikari> Erm... but "how fast it can get it off the disk" is improved by reordering [01:54:37] <Dark_Shikari> unless you actually think that grep goes as fast as dd [01:54:55] <Dark_Shikari> this is a fact, this has already been done and tested [01:55:05] <Dark_Shikari> there was a paper in which a guy modified open() to take a list of future-to-be-accessed files [01:55:06] <ohsix> hurrrrrrrrr [01:55:08] <Dark_Shikari> and changed grep to do this [01:55:12] <Dark_Shikari> it vastly improved performance [01:55:20] <Dark_Shikari> of course, it can probably nowadays be done without modifying syscalls. [01:55:29] <Dark_Shikari> making it slightly more practical. [01:55:41] <ohsix> files are one thing, metadata reads are slow, and so is opening files [01:55:48] <Dark_Shikari> opening files is nearly free [01:55:51] <Dark_Shikari> almost all inodes are cached [01:56:02] <ohsix> :< [01:56:06] <astrange> It's regarding license issue, I believe that XVID encoder is the only [01:56:06] <astrange> MPEG4 encoder that doesn't required royalty when using it. [01:56:08] <astrange> ???? [01:56:12] <Dark_Shikari> astrange: an idiot [01:57:29] <ohsix> it lives in mm/madvise.c if you want to look; along with the rest of the vm stuff [01:57:52] <Dark_Shikari> oh, cool. [01:57:53] <Dark_Shikari> thx [01:58:35] <ohsix> now you can look at my backtrace :) [02:03:03] <Dark_Shikari> ? [02:03:54] <ohsix> 17:51 < ohsix:#ffmpeg-devel> does this look weird to you btw http://paste.ubuntu.com/394242/ [02:04:25] <astrange> is that an out of pictures assertion? [02:04:34] <ohsix> the one and only [02:04:39] <astrange> if so does gst override release_buffer and then sometimes not release them? [02:05:02] <ohsix> i can look in a minute, busy with something at the moment, looking at the nal stuff though, is that right for buf [02:05:17] <astrange> http://trac.perian.org/browser/trunk/Patches/ffmpeg-larger-internal-buffer.… [02:05:35] <astrange> i didn't investigate hard enough to bring it up here [02:27:05] <ohsix> it might very well be; i saw someone mention that when i last brough tup this abort, i didn't get a stack dump then though; the _nal thing looks suspicious, i'd hoped someone could flatly state if its correct or not [02:27:22] <ohsix> fwiw for the same content, it doesn't abort with ffplay [02:28:10] <ohsix> the nal thing being #6 0x00007fffee8bd593 in decode_nal_units (h=0xb6f800, buf=0x8 <Address 0x8 out of bounds>, buf_size=518) at libavcodec/h264.c:2537 [02:28:45] <astrange> it's normal [02:29:07] <astrange> debuginfo is inaccurate in most compilers with optimizations [02:29:28] <astrange> (this is much improved in gcc 4.5) [02:29:39] <ohsix> is it aptly named? it is dereferenced [02:30:23] <ohsix> (thats as far as i looked) [02:31:05] <ohsix> avpkt looks weird too #7 0x00007fffee8bdea6 in decode_frame (avctx=0x9487d0, data=<value optimized out>, data_size=0x7fffee66abec, avpkt=0xffffffffffffffff) at libavcodec/h264.c:2749 [02:31:19] <Dark_Shikari> it's gdb. [02:32:04] <ohsix> well i have a build here without any optimization i can get a trace from, what places fault only with gdb? [02:32:07] <astrange> the problem is with the debuginfo generation, not the debugger [02:32:24] <Dark_Shikari> well yeah [02:32:27] <astrange> but you don't need any of that anyway [02:32:39] <astrange> just what the assert prints and a sample [02:33:18] <ohsix> i have both, but the bug persists :P [04:23:22] <ohsix> badnasty gdb has been dispatched, http://paste.ubuntu.com/394447/ [04:24:46] <ohsix> someone could have just said that buf is data from gst_ffmpegdec_frame ololol [04:25:43] <ohsix> astrange: does it look like your buffer thing? it doesn't do it with ffplay [04:37:30] <ohsix> astrange: dump with your patch applied (it does the same thing, but it takes a bit longer) http://paste.ubuntu.com/394452/ [04:38:05] <ohsix> i can point you to the sample and how to reproduce it [05:07:54] <ohsix> http://paste.ubuntu.com/394462/ heres the last 1000 lines of the spew from ffmpeg before it explodes [05:43:59] <ohsix> its weird, for all the years i've used ffdshow theres not been a single file of any sort i've had trouble with; yet its like every other file with totem/gstreamer + essentially the same bits behind the scenes [05:56:52] <CIA-92> ffmpeg: conrad * r22493 /trunk/libavformat/oggparseogm.c: oggdec: Set packet duration for ogm streams [05:56:53] <CIA-92> ffmpeg: conrad * r22494 /trunk/libavcodec/vp3.c: vp3: Simplify init_block_mapping [05:56:54] <CIA-92> ffmpeg: conrad * r22495 /trunk/libavcodec/vp3.c: vp3: Init MVs to 0 [05:56:54] <CIA-92> ffmpeg: conrad * r22496 /trunk/libavcodec/vp3.c: vp3: Use memset to clear the fragment array [05:56:54] <CIA-92> ffmpeg: conrad * r22497 /trunk/libavcodec/vp3.c: vp3: we only need a temp MV array of size 4 [05:56:55] <CIA-92> ffmpeg: conrad * r22498 /trunk/libavcodec/vp3.c: vp3: Make fragment_width _height by plane [06:00:08] <CIA-92> ffmpeg: conrad * r22499 /trunk/libavcodec/vp3.c: vp3: remove unneeded error, this is internal and doesn't happen [06:00:08] <CIA-92> ffmpeg: conrad * r22500 /trunk/libavcodec/vp3.c: theora: Add support for 4:2:2 and 4:4:4 subsampling [09:05:28] <kshishkov> heh, http://c0389161.cdn.cloudfiles.rackspacecloud.com/dyn/str_strip/312503.full… [09:44:17] <CIA-92> ffmpeg: stefano * r22501 /trunk/ (4 files in 2 dirs): (log message trimmed) [09:44:17] <CIA-92> ffmpeg: Move error code definitions from libavcodec/avcodec.h to [09:44:17] <CIA-92> ffmpeg: libavutil/error.h. [09:44:17] <CIA-92> ffmpeg: Error code definitions and handling code belong to libavutil, where [09:44:17] <CIA-92> ffmpeg: they can be shared by all the libav* libraries. [09:44:18] <CIA-92> ffmpeg: See the thread: [09:44:19] <CIA-92> ffmpeg: Subject: [FFmpeg-devel] [PATCH] Move error codes definitions from lavc to lavu [09:53:36] <CIA-92> ffmpeg: stefano * r22502 /trunk/libavutil/error.h: [09:53:36] <CIA-92> ffmpeg: Add missing parentheses around the AVERROR_PATCHWELCOME macro [09:53:36] <CIA-92> ffmpeg: definition. [10:00:25] <CIA-92> ffmpeg: stefano * r22503 /trunk/doc/APIchanges: Add APIchangelog entry for the libavutil/error.h addition. [10:05:54] <DonDiego> moin [10:06:04] <DonDiego> libavformat/matroskaenc.c:913: warning: suggest parentheses around && within || [10:06:12] <DonDiego> lame warning candidate of the day.. [10:08:58] <kshishkov> bah [10:09:37] <kshishkov> the most idiotic I've seen is about array index bigger than array size in dca.c [10:10:00] <kshishkov> and it can't be so because of condition before accessing array [10:14:01] <DonDiego> you misunderstant [10:14:03] <DonDiego> d [10:14:37] <DonDiego> i consider the warning lame because nobody, especially not the dev who caused it can be bothered to fix it [10:15:32] * kshishkov points to the warning at vc1dec.c [10:18:53] <astrange> ohsix: it sounds like a buffer leak bug in gst ffmpeg's release_buffer callback [10:19:04] <astrange> ohsix: of course if gst doesn't have one of those, it might not be [10:21:17] <Yuvi> DonDiego: yo [10:22:00] <Yuvi> DonDiego: so the only major theora work left in my tree is mc of entire mbs at once [10:22:57] <Yuvi> which I'm going to hold of on merging until -mt since it'll probably make astrange rewrite it again [10:23:15] <Yuvi> what problems were you having with seeking? [10:23:23] <DonDiego> artifacts [10:23:31] <Yuvi> with all files? [10:23:57] <DonDiego> i think so [10:24:03] <DonDiego> i'll give you details later [10:24:12] <DonDiego> my trees are compiling right now [10:24:23] <DonDiego> and i have a visitor for breakfast :) [10:24:31] <Yuvi> ah [10:24:53] <DonDiego> anyway, i'm superglad you've come this far [10:24:59] <DonDiego> this is great news.. [10:25:08] <Yuvi> I know seeking doesn't work well if there aren't many pages or keyframes aren't flushed quite right [10:25:09] * DonDiego hails Yuvi [10:25:13] * DonDiego hails Yuvi some more [10:25:26] * DonDiego hails Yuvi until his arms are tired and his throat is sore [10:25:50] <astrange> i'm porting the reordered_opaque pts method from ffplay to ffmpeg [10:26:19] <astrange> after that i think there are no issues merging mt theora [10:26:35] <CIA-92> ffmpeg: conrad * r22504 /trunk/libavcodec/vp3.c: [10:26:35] <CIA-92> ffmpeg: vp3: Split out motion vectors to their own array [10:26:35] <CIA-92> ffmpeg: 1.5% faster overall decode on my penryn [10:26:51] <astrange> and hopefully nobody will write error resilience or fill_edges support for it just yet [10:27:40] <astrange> Yuvi: for "for sse2 it's nearly a wash between the added check vs. the time saved" do you mean loading dct coefficients into an xmm register and checking for all zeros in that? [10:28:37] <Yuvi> astrange: no, I meant for doing doing the idct assuming they were zero (e.g. it's checked outside the call by last nnz) [10:42:17] <CIA-92> ffmpeg: stefano * r22505 /trunk/libavfilter/vf_slicify.c: (log message trimmed) [10:42:18] <CIA-92> ffmpeg: Extend the slice filter to make it issue slice height values randomly [10:42:18] <CIA-92> ffmpeg: choosen between 8 and 32 when the supplied parameter is the string [10:42:18] <CIA-92> ffmpeg: "random". [10:42:18] <CIA-92> ffmpeg: This is useful for testing the slice support, but it is not supposed [10:42:18] <CIA-92> ffmpeg: to be used by the user for other purposes and this interface may [10:42:19] <CIA-92> ffmpeg: change in the future, and thus it is not documented. [11:27:59] <CIA-92> ffmpeg: stefano * r22506 /trunk/libavfilter/ (avfilter.c avfilter.h defaults.c): [11:27:59] <CIA-92> ffmpeg: Add AVFilterPic.pos field and make libavfilter propagate stream byte [11:27:59] <CIA-92> ffmpeg: position information, as stored in the pkt.pos, through the [11:27:59] <CIA-92> ffmpeg: filterchain. [11:27:59] <CIA-92> ffmpeg: Note that the pos field is added *non* at the end of the [11:27:59] <CIA-92> ffmpeg: AVFilterPicRef struct, thus breaking ABI compatibility, which is [11:28:00] <CIA-92> ffmpeg: allowed as the API is still considered non-stable. [11:28:00] <CIA-92> ffmpeg: stefano * r22507 /trunk/ffplay.c: [11:28:01] <CIA-92> ffmpeg: Make ffplay pass the packet.pos information to the filterchain, get it [11:28:01] <CIA-92> ffmpeg: again from the filterchain and pass it back to output_picture2(). [11:42:05] <CIA-92> ffmpeg: stefano * r22508 /trunk/ (libavfilter/avfilter.h doc/APIchanges): [11:42:06] <CIA-92> ffmpeg: Bump libavfilter minor version and add APIchanges entry after the [11:42:06] <CIA-92> ffmpeg: addition of the AVFilterPicRef.pos field. [12:34:51] <CIA-92> ffmpeg: stefano * r22509 /trunk/libavfilter/vf_scale.c: [12:34:51] <CIA-92> ffmpeg: Make the scale filter pass the pkt.pos information to the output [12:34:51] <CIA-92> ffmpeg: picref. [13:19:52] <Dark_Shikari> Yuvi: awesome, you did the DC only idct [13:19:53] <Dark_Shikari> let me check that patch [13:50:42] <Kovensky> Honoome: there? [15:15:32] <DonDiego> mpeg12.c:2299: undefined reference to `ff_vdpau_mpeg_picture_complete' [15:15:38] <DonDiego> anybody seeing the same error? [15:15:54] <DonDiego> ./configure --enable-gpl --enable-postproc --disable-mmx2 --disable-sse && make [15:32:33] <DonDiego> Yuvi: still around? [15:44:12] <DonDiego> Yuvi: did you see all the theora/ogg bugs i assigned to you in roundup? [15:44:24] <DonDiego> some may still be valid, dunno [15:44:47] <DonDiego> also, what is the status of all those crashers that Dark_Shikari found by fuzzing? [15:44:56] <DonDiego> Dark_Shikari: maybe you can tell me as well.. [15:47:10] <DonDiego> lu_zero: the roundup certificate expired... [15:50:05] <DonDiego> Yuvi: [theora @ 0x74ebc4]7 bits left in packet 82 [15:50:11] <DonDiego> that looks like spam to me :) [15:50:28] <Dark_Shikari> looks like ogg to me [15:52:15] <mru> the difference? [15:52:30] <Dark_Shikari> the file the spam is from? [15:52:37] <Dark_Shikari> also, that same spam occurs for a whole lot of container formats iirc [15:53:16] <DonDiego> well, my point is that i don't think the console should be spammed with debug messages like this [15:53:30] <DonDiego> who cares how many bits were left in packet X? [15:53:42] <Dark_Shikari> I agree, it should be left for verbose/debug mode [15:53:52] <Dark_Shikari> then again, there _shouldn't_ be any bits left [15:54:30] <DonDiego> Yuvi http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/322x242_not-divi… [15:54:50] <DonDiego> mplayer places a black bar somewhere in the top of the image [15:55:00] <DonDiego> with ffmpeg, but not with libtheora [15:55:14] <DonDiego> can somebody verify with ffplay (my ffplay keeps crashing) [15:56:35] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/320x240.skeleton… [15:56:42] <DonDiego> this file seriously spams the console [15:57:06] <DonDiego> [ogg @ 0x74cf04]Packet is missing granule [15:57:11] <DonDiego> gets printed ad infinitum [15:58:44] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/multi2.ogg [15:58:51] <DonDiego> that file fails to play at all with [15:58:53] <DonDiego> LAVF_header: av_open_input_stream() failed [15:59:15] <DonDiego> again with mplayer, but libtheora works fine [15:59:29] <DonDiego> (confirmation with ffplay still appreciated..) [16:00:23] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/mobile_itu601_i_… [16:00:37] <DonDiego> this one fails with mplayer unsuccessfully looking for a matching colorspace [16:00:52] <DonDiego> could be an mplayer problem, but again libtheora is fine [16:01:00] <siretart`> DonDiego: regarding the ia64 FTBFS, I cannot reproduce it on the debian porterbox [16:01:30] <DonDiego> siretart`: weird.. [16:01:37] <DonDiego> any special cflags? [16:01:42] <DonDiego> on either box? [16:01:54] <siretart`> DonDiego: it might be fixed in gcc 4.4.3. fate tests with 4.4.2 [16:02:22] <siretart`> or maybe fate is using problematic cflags [16:02:54] <siretart`> I'll reconfigure with fate's configure flags [16:03:12] <DonDiego> ideally the fate boxes should not use any special flags.. [16:06:54] <mru> siretart`: the ia64 errors happen only with --enable-shared [16:07:16] <mru> static build is fine [16:07:24] <siretart`> still compiling here [16:07:42] <siretart`> and I thought ia64 were fast.. ha [16:08:16] <mru> it can be fast [16:08:27] <mru> if you manage to write good code [16:08:30] <Dark_Shikari> "ia64" "fast" [16:08:42] <Dark_Shikari> did those things even have simd?> [16:08:46] <Dark_Shikari> other than x86_32 legacy simd [16:08:46] <mru> writing good code for ia64 is still an unsolved problem [16:08:53] <mru> don't know [16:09:00] <mru> it's a vliw architecture [16:09:09] <mru> and gcc *really* sucks with those [16:09:10] <Dark_Shikari> it only does 3 operations per vliw though [16:10:10] <Kovensky> more funny acronyms? [16:10:31] <mru> very long instruction word [16:10:44] <mru> it was all the rage in the 90s [16:10:52] <Kovensky> heh [16:11:01] <Kovensky> hmm, IIRC it had some funny instruction length [16:11:06] <Kovensky> it was 41-bit IIRC [16:11:12] <mru> no [16:11:30] <mru> maybe each instruction within a bundle is some odd length [16:11:43] <mru> but they'll always come in word-aligned groups [16:11:50] <Kovensky> hmm [16:11:52] <siretart`> mru: do you have a clue *why* ffmpeg fails to build on ia64? [16:11:58] <mru> yes [16:11:59] * Kovensky should find again the page where he saw that but :effort: [16:12:03] <mru> the error message says it all [16:12:35] <mru> it's trying to shove a >4MB offset into 22 bits [16:12:35] <Kovensky> CC /usr/home/kovensky/src/kovensky/build/build_libs/lib/libavcodec.a [16:12:35] <Kovensky> CC /usr/home/kovensky/src/kovensky/build/build_libs/lib/libavcodec.a [16:12:37] <Kovensky> o_O [16:12:47] <mru> uh? [16:12:53] <Kovensky> huh indeed [16:13:00] <Kovensky> it apparently is using a silent makefile [16:13:03] <mru> how did you manage that? [16:13:06] <Kovensky> no idea [16:13:10] <Kovensky> I just git pulled and ran make [16:13:11] <Kovensky> lol [16:13:30] <Kovensky> more importantly, it's showing the wrong filename on the CC lines [16:13:31] <mru> make config and try again [16:13:54] <Kovensky> (forgot to mention it was reconfigured) [16:14:01] <mru> configure line? [16:14:33] <mru> 'cause it does the right thing here [16:14:35] <siretart`> mru: is this something we can fix in ffmpeg? the fact that gcc 4.5 manages to compile it makes we wonder... [16:14:40] <mru> no [16:15:06] <siretart`> ok [16:15:07] <mru> gcc seems to assume .bss will never be more than 4MB away from .text [16:15:16] <mru> which is pretty insane [16:15:22] <mru> our .bss is ~5MB [16:15:38] <siretart`> oh, I see. thanks for explanation [16:16:47] <peloverde> siretart`, DonDiego: Is there anything I can do to help with the release? [16:17:13] <Dark_Shikari> run the fuzzer on mp4, mkv, h264, aac, ogg, theora, vorbis? ;) [16:18:26] <DonDiego> peloverde: find out if there are any regressions or important bugs that are pending [16:18:58] <DonDiego> peloverde: confirm the problems with theora i wrote about above in ffplay [16:19:08] <DonDiego> check fate, there are a bunch of failures [16:19:10] <siretart`> okay, I can reproduce the ia64 link problem with --enable-shared. [16:19:18] <siretart`> but I think we can ignore that for 0.6 [16:20:29] <DonDiego> mru: is it normal that avr and blackfin fail so many tests? [16:21:12] <mru> they always do [16:21:33] <mru> gcc-avr32 is incredibly buggy [16:21:34] <DonDiego> so no need to keep them on the radar for the release? [16:22:35] <mru> I don't think anyone really cares [16:22:43] <DonDiego> ok, fine then [16:22:55] <DonDiego> ramiro: what about cygwin fate failures? [16:23:55] <DonDiego> and then there is mac os x powerpc regtests [16:24:34] <DonDiego> TEST VCODEC dnxhd_720p_rd [16:24:39] <DonDiego> this one fails there.. [16:58:25] <DonDiego> peloverde: and thanks for the offer to help out with the release, it's much appreciated [17:14:48] <siretart`> and also many thanks to all who offered to translate the release notes! [17:15:15] <BBB> you forget that for native speakers in whatever language, this is no effort whatsoever :) [17:16:16] <sancode> Hello. [17:17:11] <kshishkov> BBB: try understanding English first [17:17:55] <BBB> you're suggesting my english is poor :( [17:18:12] <kshishkov> no, only the fact you forgot one condition [17:26:20] * BBB conceeds [17:27:02] <kshishkov> BBB: while you're at it, you can translate something into Dutch from Zulu or Quechua [17:27:37] <siretart`> How about release notes in Quenya? ;-) [17:27:52] <kshishkov> Sindarin [17:28:17] * BBB has most of the zulu -> dutch is easy [17:28:18] <kshishkov> and we need to agree on who edits final translation to Japanese [17:28:26] <BBB> dutch -> zulu would take a zulu speaker [17:28:32] <BBB> what's quenya? [17:28:46] <BBB> wait, that first sentence was weird [17:28:51] <BBB> why don't we cut the first half of it [17:28:54] <BBB> then it makes sense [17:29:04] <kshishkov> BBB: elfish language invented by JRRT after being exposed to Finno-Ugric languages [17:29:36] <siretart`> BBB: high elfish, language of the elders [17:29:56] <BBB> uh [17:29:57] <BBB> no [17:29:58] <BBB> :) [17:30:22] <Dark_Shikari> translate it to orkish [17:30:29] <kshishkov> nazghul [17:30:50] <Dark_Shikari> no, I mean warhammer 40k ork [17:30:51] <Dark_Shikari> ;) [17:31:53] <kshishkov> or that language in Myst [17:32:17] <kshishkov> and don't you dare to forget Klingon [17:32:44] <Kovensky> lojban? [17:33:04] <kshishkov> no [17:33:19] <kshishkov> it does not compile anyway [17:42:13] <BBB> what does a complex multiplication of x = {re1, im1}, y = {re2, im2}; x * y= ..? look like? [17:42:51] <peloverde> real part: re1*re2 - im1*im2 [17:43:08] <peloverde> imaginary part re1*im2 + im1*re2 [17:43:48] <elenril> simply (re1 + i*im1)(re2 + i*im2) [17:43:50] <BBB> do we have a function for that in FFmpeg? [17:43:59] <kshishkov> look in fft.c ;) [17:44:32] <kshishkov> BBB: at least you're unlikely to meet quaternions :) [17:44:43] <peloverde> BBB, c99 complex.h supports it. we don't require c99 complex.h :( [17:44:58] <BBB> oh, unlovely :( [17:47:09] <kshishkov> BBB: you should try to write FFT implementation from scratch at least once in your life [17:47:17] <BBB> I already did [17:47:23] <BBB> without knowing it at that point [17:47:32] <BBB> I RE'ed the FFT in wmavoice [17:47:35] <BBB> that's FFT right there [17:47:53] <kshishkov> I usually skip such parts [17:48:05] <BBB> I would if I had to do it again [18:08:54] <ohsix> astrange: thanks, you might be on to something; last time there was an event similar in the log there were a _bunch_ of release buffer messages [18:14:18] <ohsix> BBB: what was your unknowing fft? [18:18:15] <CIA-92> ffmpeg: aurel * r22510 /trunk/libavcodec/avcodec.h: bump minor avcodec version for libxvid codec id change (r22489) [18:19:13] <BBB> ohsix: I have no idea what I'm doing [18:19:22] <ohsix> :> [18:19:22] <BBB> ohsix: that doesn't mean what I'm doing could not be fft [18:19:34] <kshishkov> BBB: look at libavcodec/truespeech.c again [18:19:34] <ohsix> i see [18:19:46] <ohsix> has someone pointed you to that dspguru book yet? [18:19:59] <BBB> kshishkov: well, :) [18:20:23] <CIA-92> ffmpeg: aurel * r22511 /trunk/libavcodec/avcodec.h: CODEC_ID_XVID is not used anywhere, remove it at next major bump [18:20:37] <kshishkov> BBB: that's a good example of someone not knowing what he does and noone to explain it to him either [18:21:06] <BBB> lol :) [18:21:13] <BBB> kshishkov: would you want me at some point to rewrite that? [18:21:14] <kshishkov> but it's true [18:21:30] <BBB> didn't mike re a codec at some point where he had no idea what he was doing? [18:21:33] <kshishkov> BBB: you'd better write encoder for it, it was requested [18:21:35] <BBB> and then someone redoing it 10 yrs later? [18:22:00] <kshishkov> I don't have a slightest idea about what Xan codec you're speaking about [18:22:25] <BBB> if I do a complex FFT (i.e. not RDFT), are only the first 0x82 filled out after fft()? [18:22:29] <BBB> and the rest empty? [18:22:32] <BBB> (7-bit-radius fft) [18:22:52] <kshishkov> s/radius/radix/ [18:23:00] <BBB> :) [18:23:10] <BBB> see, I have no friggin' clue what I'm talking about ;) [18:23:18] <BBB> but is it true? [18:23:39] <kshishkov> first of all, FFTs employed are usually have lengths = power of two [18:23:55] <BBB> so I have FFTComplex[0x80] as input, and after fft(), only the first the first [0x41] are filled? [18:24:23] <kshishkov> theoretically it should fill all 0x80 elements [18:24:29] <ohsix> it doesn't fill the other half with something too? [18:25:21] <kshishkov> every frequency affects all samples after all, something like that for time->frequency domain translation too [18:26:44] <kshishkov> BBB: if it fills only first 64 complex numbers maybe it's 64-point FFT [18:28:16] * BBB goes try his theory that one of his calcs is actually FFT instead of RDFT [18:28:20] * BBB wonders how to test that [18:29:16] <kshishkov> see whether it ignores imaginary part of output or not [18:31:22] <BBB> the binary does [18:31:30] <BBB> but here's the thing: the binary has many bugs already [18:32:01] <BBB> and it actually calculates the output of fft(), and then does ifft(), ..., fft() and that's the end of it [18:32:13] <BBB> but when calculating the initial values, im[0] and im[0x40] are not(!) zero [18:32:40] <BBB> suggesting that it represents the fft of something where the input was not merely real [18:32:42] <BBB> right? [18:32:49] <kshishkov> yes [18:32:58] <BBB> so I think the binary screws up [18:33:15] <BBB> so I want to see if output improves if I do actual FFT instead of RDFT [18:33:38] <BBB> of course I could easily totally screw up [18:33:45] <BBB> but that's ok, since I don't know what I'm doing anyway [18:33:59] <kshishkov> d'you wanna end with yer decoder producing better crap than original? [18:37:16] <BBB> it already does! [18:37:32] <BBB> much better, in fact, particularly in low-bitrate mode [18:37:57] <BBB> I don't care much about the binary, I want to know the theory of music / speech encoding [18:38:04] <BBB> merely reproducing the binary isn't very interesting [18:38:12] <BBB> understanding it and improving it where possible, is much cooler [18:38:32] <kshishkov> read a paper by Noll then [18:39:02] * BBB will first just try random things [18:39:17] <BBB> I currently just let the code modify data, print data before/after, print the results in a graph and see what it did [18:39:24] <BBB> "aha, so that's what $process is/does" [18:40:11] <kshishkov> BBB: read papers from here. http://www.eas.asu.edu/~spanias/papers.html [18:43:34] <peloverde> IMHO you have to be very careful about "improving" the quality in comparison to the binary on such codecs, at some point they may recognize those bugs as part of the format and try to work around them in the encoder [18:44:09] <kshishkov> M$? work around bugs? [18:44:21] <kshishkov> they are famous for bug-for-bug compatibility! [18:44:50] <peloverde> that's exactly what I'm saying [18:44:59] <peloverde> so the decoder, stays invariant [18:45:30] <peloverde> and instead tehy release an improved encoder that spits out better output for the mathematically unsound decoder [18:45:50] <peloverde> all previous bitstreams are bug for bug compatible [18:46:35] <kshishkov> are they known for actually _improving_ stuff either? [18:46:36] <peloverde> One there is only one decoder, it isn't a bug in the decoder, it's a flaw in the format [18:47:37] <BBB> peloverde: well, I'm not sure [18:48:06] <BBB> peloverde: my impression, from looking over the postfilter, is that there's a lot of crap in here that shouldn't be there, made up to improve the bastardized output of the pure speech synthesis part itself [18:48:11] <BBB> anyway [18:48:15] <BBB> it sounds good, so I think it's fine [18:48:20] <peloverde> ok [18:48:30] <BBB> I agree I shouldn't go too far [18:49:09] <kierank> hmm I wonder what "Dolby E Encoder Simulation" refers to [18:49:43] <kshishkov> kierank: more context please [18:49:56] <ohsix> is it actual speech synthesis? cuz there often is a bunch of garbage tacked on those things to make it sound better [18:50:40] <BBB> postfilter [18:50:41] <BBB> right [18:50:46] <BBB> all I'm looking at now is postfilter [18:51:35] <kierank> kshishkov: It's just a string that seems to be at the beginning of the Dolby decoding api [18:52:13] <kshishkov> kierank: probably just encoder name, ignore it [18:59:58] <BBB> interesting audio effect [19:00:03] * BBB probably screwed up somewhere [19:11:26] <BBB> is this a lowpassfilter? http://people.gnome.org/~rbultje/lowpassfilter.png [19:12:03] <mru> not a very good one [19:12:20] <peloverde> BBB, is that the same thing we were discussing thusday? [19:12:24] <BBB> no [19:12:35] <BBB> different piece of code [19:12:36] <mru> BBB: can you plot output/input [19:12:44] <mru> and also log(output/input) [19:12:57] <mru> by frequency of course [19:13:21] <peloverde> Do you have coefs for this filter? [19:20:31] <CIA-92> ffmpeg: stefano * r22512 /trunk/ (libavcodec/iff.c libavutil/error.h): [19:20:31] <CIA-92> ffmpeg: Make iff.c:decode_init return the value returned by [19:20:31] <CIA-92> ffmpeg: avctx->get_buffer() in case of error, rather than AVERROR_UNKNOWN [19:20:31] <CIA-92> ffmpeg: which is deprecated, and mark AVERROR_UNKNOWN for deletion at the next [19:20:31] <CIA-92> ffmpeg: major bump. [19:20:32] <CIA-92> ffmpeg: stefano * r22513 /trunk/ (7 files in 3 dirs): [19:20:33] <CIA-92> ffmpeg: Replace all the occurrences of AVERROR_EIO with AVERROR(EIO), and mark [19:20:33] <CIA-92> ffmpeg: AVERROR_EIO for deletion at the next major bump. [19:20:34] <CIA-92> ffmpeg: stefano * r22514 /trunk/libavutil/error.h: [19:20:34] <CIA-92> ffmpeg: Mark AVERROR_ENOMEM to be deleted at the next major bump. [19:20:35] <CIA-92> ffmpeg: AVERROR(ENOMEM) must be used instead, and there are no occurrences of [19:20:35] <CIA-92> ffmpeg: AVERROR_ENOMEM in the FFmpeg basecode so it can be safely dropped. [19:27:15] <ramiro> DonDiego: things are failing randomly on my vboxes. it started failing last week or so. I guess the ram has gone bad. [19:28:04] <ramiro> usually it's only one cygwin test or so, but I got an ICE compiling on mingw a couple of days ago that had never happened. [19:28:46] <ramiro> the cygwin errors are always signal 15. it might be a bug in cygwin. [19:42:52] <BBB> peloverde: no coefficients, this is an actual FFT-based filter [19:43:16] <peloverde> BBB, so then what does the FFT of the filter look like? [19:43:23] <BBB> mru: what you saw was input/output FFT (frequencies), so you want log-based instead? [19:43:32] <BBB> peloverde: it's very large [19:43:41] <BBB> it's multiple functions [19:43:59] <BBB> shall I post the whole patch online? [19:46:40] <peloverde> If it's that final computed FFT domain function, it may be harder to name than just lowpass, highpass, bandpass, etc [19:47:14] <BBB> http://people.gnome.org/~rbultje/lowpassfilter2.png [19:47:19] <BBB> log-based frequencies [19:47:20] <kshishkov> depends on manipulation type [19:47:29] <peloverde> siretart`, I found one issue with the SBR decoder, biasing for int_to_float_16_c causes us to lose precision when the signal is very small [19:47:54] <BBB> peloverde: yes it's that one [20:09:22] <peloverde> my guess is that it's some sort of matched emphasis filter [20:11:27] <peloverde> siretart`, DonDiego, I have one AAC fix coming down the pipe [20:14:50] <siretart`> peloverde: cool! you rock! [21:04:43] <pasteeater> superdump: is your server/site dead? i've been getting timeouts for a week. [21:05:11] <pasteeater> or maybe a few days. can't remember. [21:05:45] <superdump> since the concepcion earthquake [21:05:50] <superdump> it's offline [21:06:02] <superdump> i don't know what's happening with it [21:06:12] <superdump> i may just start a new blog somewhere else [21:06:46] <pasteeater> was it located in Chile? [21:06:49] <superdump> yes [21:08:45] <pasteeater> i guess that was a dumb question. [21:13:05] <CIA-92> ffmpeg: alexc * r22515 /trunk/libavcodec/ (aac.c aacsbr.c): aac: Don't bias output during the IMDCT if SBR will be used. [21:13:05] <CIA-92> ffmpeg: alexc * r22516 /trunk/libavcodec/aacsbr.c: aacsbr: DSPUtilize analysis input scaling. [21:14:11] <peloverde> siretart`, DonDiego: AAC fixes applied. AAC verfied on amd64 4.4.3-3ubuntu3, amd64 (noasm) 4.4.3-3ubuntu3, amd64 clang-svn. [21:16:34] <pasteeater> siretart`: i'm the one who submitted LP 538555 by the way, but i'm going to be out of town for a week, in case i don't respond... [22:47:28] <Yuvi> DonDiego: saw the bugs, I don't know much about vorbis but I'll look at them [22:47:54] <Yuvi> DonDiego: mplayer fixed with non-4:2:0 [22:53:06] <DonDiego> Yuvi: a bunch of the bugs are not about vorbis, but about ogg and theora, most of them i think [22:53:13] <Yuvi> yeah [22:54:57] <DonDiego> can we quickly go over the theora status in trunk? [22:55:08] <DonDiego> IIUC you merged all your speedup work, right? [22:56:30] <Yuvi> not quite, DC-only is pending (will apply w/ michaels comments really soon), and I'm going to wait until -mt is merged to do MC of entire MBs at once (since it's likely to make astrange rewrite -mt again) [22:56:39] <Yuvi> but other than that it should be merged [22:56:55] <Yuvi> multi2.ogg works in ffplay, but not mplayer, hm [22:57:31] <DonDiego> how much speedup does dc-only provide? [22:57:38] <Yuvi> 2-4% [22:57:43] <DonDiego> good stuff [22:58:06] <DonDiego> what about the console spam? :) [23:01:00] <J_Darnley> Yuvi: If you are working on ogg, do you plan on altering vorbis header writing? [23:01:54] <Yuvi> DonDiego: let me see if that persists when I move the warning to the right place, I'd still like to complain about those invalid files [23:02:13] <DonDiego> i cannot believe that *all* ogg files are invalid [23:02:33] <Yuvi> dunno why mplayer is complaining so, ffplay doesn't [23:02:38] <Yuvi> J_Darnley: not in the muxer [23:02:46] <J_Darnley> ok [23:02:59] <DonDiego> hmm, i need to test in ffplay, but it does not work on os x right now.. [23:03:21] <Yuvi> get a half-working sdl? (fully working sdl on os x is impossible I think) [23:04:06] <Yuvi> or maybe they broke it on ppc [23:07:45] <DonDiego> yeah, i suspect sdl is at fault [23:08:10] <DonDiego> i'm recompiling on my x86 box, but it's slow.. [23:09:16] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/322x242_not-divi… [23:09:25] <DonDiego> Yuvi: does this sample work properly for you? [23:10:32] <Yuvi> the black bar seems to be something weird going on in mplayer's, it happens for snow too [23:10:39] <Yuvi> except worse [23:10:50] <DonDiego> k [23:12:32] <DonDiego> Yuvi: so what else do you have on your plate? [23:12:43] <DonDiego> what about all the bugs that the fuzzing uncovered? [23:16:20] <Yuvi> main think I think is making seek work well, there's too many situations it doesn't (due to the whole granule is the end time not interacting with lavf's generic binary search) [23:16:43] <DonDiego> k [23:17:03] <DonDiego> btw, by spam i meant the "X bits left in packet 82" thing [23:17:16] <DonDiego> that looks quite bogus and gets printed for every file [23:17:16] <Yuvi> I should get that mostly done today, then I'll do fuzz bugs [23:17:51] <DonDiego> cool [23:18:22] <DonDiego> oh, the amount of beer that i owe you :) [23:18:23] <Yuvi> that spam I'm not entirely sure about because I don't think I've ever looked at what's in the third header packet [23:29:08] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/mobile_itu601_i_… [23:29:19] <DonDiego> Yuvi: that video gets stuck with ffplay for me [23:29:36] <DonDiego> mplayer works fine with libogg/libtheora [23:31:46] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/ED-small-sample-file.ogg [23:31:53] <DonDiego> that one gets stuck similarly [23:32:08] <DonDiego> and crashes when quitting [23:32:20] <DonDiego> glibc detected invalid pointer or whatnot [23:33:30] <Yuvi> weird, they both work for me with ffplay [23:37:16] <DonDiego> well, the crash might be related to some of the bugs the fuzzer uncovered [23:37:19] <Yuvi> so 320x240.skeleton+cmml.ogv does indeed appear to be invalid despite being in the theora testsuite [23:37:37] <DonDiego> oh, i'm not surprised [23:37:54] <kierank> lol [23:37:59] <DonDiego> i was the one to notice that all the files in the testsuite originally were invalid :) [23:38:33] <DonDiego> see the theora_testsuite_invalid directory [23:38:48] <DonDiego> i ran that ogg verification tool that they have against them [23:38:54] <DonDiego> there was a muxing bug.. [23:39:26] <Yuvi> heh

1 0

IRC log for 2010-03-12
by irc＠mansr.com 13 Mar '10

13 Mar '10

[00:03:17] <mika_video> Hello! I think I just found a bug in function which starts at line 2974 of file libavformat/utils.c : 02974 void dump_format(AVFormatContext *ic, .... actual bug: lines 02980-02982 : uint8_t *printed = av_mallocz(ic->nb_streams); if (ic->nb_streams && !printed) return; [00:03:19] <mika_video> I think it should return immediately if either (ic->nb_streams == 0) OR (printed == null) // i assume av_mallocz returns null if it fails to allocate memory. [00:03:24] <mika_video> Should it be rewritten as: if ( (ic->nb_streams == 0) || (printed == NULL) ) return; [02:10:59] <kierank> it seems the Dolby E API is based on a floppy disk based authentication system [02:11:29] <mru> floppy disk based auth system??? [02:11:59] <kierank> you put your floppy disk in and it authenticates you to use the api [02:16:50] <mru> and that's supposed to be secure? [02:17:04] <mru> well, in the sense that _nobody_ has a floppy drive I guess it might be... [02:17:11] <mika_video> <kierank>: Very interesting! What if I install windows (2000/XP) into a virtualbox running on linux and mount a diskette image to be seen as drive A: of the vurtual machine? Would the authentication succeed or fail ? [02:17:51] <kierank> http://www.paceap.com/key.html [02:18:19] <mika_video> And, can a virtual diskett image of a 3.5" floppy be something else than 80*18*2*512 bytes ? [02:19:24] <kierank> dunno. all I saw was an error message that said your "key diskette" was invalid to use the dolby e api [02:19:39] <kierank> and i guess it reflects the current up-to-dateness of dolby [02:19:40] <mika_video> I know sometimes copy protect systems have used a dloppy formatted in a nonstardard way - so it might not even have the same # of sectors on each track... I have no idea whether it is possible to have a virtual image of such nonstandard floppy ... [02:19:53] <Dark_Shikari> so apparently I just got an email from google [02:20:04] <Dark_Shikari> all-but-begging me to apply to work for them this summer [02:20:50] <kierank> enjoy working on vp8 [02:20:54] <mika_video> <Dark_Shikari>: did you see mu question about a possible bug in libavformat/utils.c ? [02:20:54] <astrange> apparently? [02:21:22] <astrange> i didn't make it through their automatic project matcher, maybe they should have bought on2 earlier [02:21:31] <Dark_Shikari> lol [02:24:09] <mika_video> does anyone know how olng the avformat_version() function has been available ? [02:24:49] <CIA-92> ffmpeg: ramiro * r22471 /trunk/doc/developer.texi: Don't use shell syntax to set variables for make. [02:25:01] <mru> since r14667 [02:25:11] <mika_video> void dump_format(AVFormatContext *ic, .... actual buggy: lines 2980-2982 : uint8_t *printed = av_mallocz(ic->nb_streams); if (ic->nb_streams && !printed) return; [02:26:41] <mika_video> how does that r14667 splitv into the major.minor.micro -format returned by avformat_version() ? [02:27:46] <mru> 52.20.0 [02:28:33] <mika_video> is there some way to calculate that ? [02:28:46] <mru> calculate from what? [02:29:10] <mika_video> calculate from r14667 to the format 52.20.0 [02:29:53] <mru> look in avformat.h for that revision [02:31:42] <mika_video> Semms ffmpeg has two totally unrelted version numberings - is that why there's an interesting comment in she source file: "unsigned avformat_version ( void ) // I return the LIBAVFORMAT_VERSION_INT constant. You got a fucking problem with that, douchebag?" [02:32:10] <Dark_Shikari> lol [02:32:13] <Dark_Shikari> I love that comment [02:32:35] <mru> first person pejorative [02:32:41] <mika_video> I'd like to talkk that into a voice file... just include that as an embedded mp3 resource in ffmpeg.exe [02:34:26] <Dark_Shikari> hmm, found a random interesting paper on h264 hardware implementations that actual has power usages and other useful stats [02:34:41] <Dark_Shikari> for a design targeting 720p @ 30fps: [02:34:53] <Dark_Shikari> 262k gates, 2.44 mm^2, 20ns clock period, 180 milliwatts [02:35:02] <mika_video> <Dark_Shikari>: what about replacing lines lines 2980-2982 of libavformat/utils.c: uint8_t *printed = av_mallocz(ic->nb_streams); if (ic->nb_streams && !printed) return; [02:35:07] <mika_video> I think it should return immediately if either (ic->nb_streams == 0) OR (printed == null) // i assume av_mallocz returns null if it fails to allocate memory. [02:35:16] <Dark_Shikari> one interesting thing is their QCIF version is only like 30k gates less [02:35:20] <mika_video> Should it be rewritten as: if ( (ic->nb_streams == 0) || (printed == NULL) ) return; [02:35:21] <Dark_Shikari> and not much slower [02:35:25] <Dark_Shikari> or simpler [02:35:40] <Dark_Shikari> which might explain why tons of hardware devices just stick 1080p asics in for the hell of it [02:39:31] <Dark_Shikari> mru: you at all familiar with how linux handles stack growth> [02:39:31] <Dark_Shikari> ? [02:39:58] <mru> unmapped page below stack [02:40:12] <Dark_Shikari> yes, but what if I have a function that allocates more than one page worth of data? [02:40:13] <mru> on a page fault it allocates a new physical page and maps it in [02:40:19] <Dark_Shikari> say, sub esp, 400000 [02:40:23] <Dark_Shikari> it'll jump the page [02:40:37] <mru> try and see [02:40:59] <Dark_Shikari> seriously though, I'm just wondering if it does it the same way windows does [02:41:01] <mru> I think it tries to keep a large unmapped zone between the stack and anything else [02:41:05] <Dark_Shikari> windows allocates a few guard pages [02:41:11] <Dark_Shikari> and if a function allocates a _huge_ amount of stack [02:41:16] <Dark_Shikari> it inserts a call to __chkstk [02:41:24] <mru> that's the compiler [02:41:26] <Dark_Shikari> which literally just touches a page at the time [02:41:27] <mru> gcc doesn't do that [02:41:29] <Dark_Shikari> mru: it's required by the ABI [02:41:30] <Dark_Shikari> yes it does [02:41:38] <mru> hmm, on windows maybe [02:41:40] <Dark_Shikari> yes, on windows [02:41:46] <Dark_Shikari> that's how windows does stack handling [02:41:50] <mru> I know [02:42:00] <Dark_Shikari> seems like a pretty good method actually [02:42:09] <mika_video> 52.20.0 - that explains why I get this: avformat_version() not found in avformat-50.dll [02:42:17] <mru> seems like you're doing something wrong if you need more than 4k in a single stack frame [02:42:31] <Dark_Shikari> ffmpeg is filled with functions that take 10 times that [02:42:41] <mru> bugs [02:42:45] <mru> should be fixed [02:42:52] <Dark_Shikari> also, large stack sizes aren't exactly unreasoanble [02:42:53] <mru> where are they? [02:42:59] <Dark_Shikari> it's more efficient than heap allocation if you intend to re-use the space [02:43:07] <Dark_Shikari> better on cache. [02:43:16] <mika_video> why use that much stack space... you could use malloc if you prefer C library functions.... [02:43:43] <Dark_Shikari> (where "large" means 4k or 8k or 32k, not 500k) [02:44:00] <mru> large is 1k [02:44:28] <mru> if you get even close to 1k in a single function you should think very carefully about what you're doing [02:44:52] <mika_video> Has anyone compiled ffmpeg using tcc instead of gcc ? [02:44:55] <mru> I've worked on systems where 2k for the entire stack was normal [02:45:10] <mru> mika_video: you joking? [02:45:21] <Dark_Shikari> mru: 1k isn't enough for the simplest possible dct trellis [02:45:23] <mru> tcc, toy c compiler [02:45:24] <mika_video> or at least some demo app using libavformat and libavcodec ? [02:45:48] <astrange> if you want faster compiles use clang (and a configuration that it doesn't miscompile) [02:45:53] <Dark_Shikari> lol [02:45:54] <mru> Dark_Shikari: maybe you shouldn't be using the stack for that [02:45:57] <Dark_Shikari> mru: why? [02:46:01] <Dark_Shikari> it's local data which will never be used again [02:46:11] <Dark_Shikari> why should we waste cachelines on it? [02:46:13] <mika_video> mru: I just want to know whether tcc will do. I do dot care about code size or speed at all. [02:46:31] <mru> Dark_Shikari: you'll use it again next time that function is called, no? [02:46:43] <Dark_Shikari> mru: it'll be long out of cache by then [02:46:49] <Dark_Shikari> L1, at least [02:46:52] <mru> so will the huge stack [02:46:56] <Dark_Shikari> no it won't [02:46:59] <Dark_Shikari> the stack will be re-used by other functions [02:47:04] <mika_video> So, if it is bif and fat code and very slow, but it compiles without errors and also does not generate runtime errors or hang the pc, then it is fine. [02:47:08] <mru> only if they also are badly written [02:47:09] <Dark_Shikari> with the stack, every single function can share the same data for its tempdata [02:47:17] <Dark_Shikari> with the heap, you can't share data unless you use scratch buffers [02:47:23] <Dark_Shikari> in which case you are duplicating the stack on the heap [02:47:24] <Dark_Shikari> and you are retarded [02:47:39] <mru> I didn't say you should never do it [02:47:42] <Dark_Shikari> gcc will always compile better code for local arrays too. [02:47:59] <mru> but 99% of all cases I've seen where a function used more than 1k of stack space were stupid [02:48:28] <Dark_Shikari> well lets look at me_refine_bidir [02:48:39] <Dark_Shikari> 18 Y, U, and V buffers used for cached interpolated data [02:49:05] <Dark_Shikari> a "visited" array of size 8*8*8 (bitfield) [02:49:13] <Dark_Shikari> total: ~7.5k [02:49:14] <mika_video> it's just that for my own reasons, I want to be able to make my own app compile C source. Tcc is available as a dll too, so that's why I like it. And, it's open source and at löeast the code is more understandable to read comared to gcc. [02:49:28] <astrange> use clang for that too [02:49:53] <mika_video> <astrange>:clang? [02:50:07] <astrange> but there's not much reason to move compilers into a library instead of just execing them [02:51:31] <mika_video> what about exc'ing mingw-gcc directly from a windows GUI app - there's no msys between translating unix-style /src/ffmpeg to C:\mingwproj\src\ffmpeg [02:52:17] <ohsix> are you trying to get around some license by compiling the code on the fly? [02:52:28] <Dark_Shikari> JIT license violation ;) [02:53:15] <mika_video> no. But using modified tcc would be one possibility to make a sanity check when automatically converting .h to other language than C [02:53:46] <mika_video> for example, to verify structure sizes and offsets of every field of a struct [02:55:22] <ohsix> but that depends on the compiler and possible compiler specific options in use at the time [02:56:09] <mru> struct layout is usually defined by the architecture ABI [02:57:21] <ohsix> i guess; you still can mess with junk though [02:57:57] <mika_video> I just cannot understand why avformat-50.dll will put the filename at byte offset 180 of AVFormatContext instead of offset 104. [02:58:47] <mika_video> It also will report 32768 streams in an mpeg file ... probably some odd mismatch between the structure organization in the dll and the header file [03:00:53] <mika_video> How about revision r15291, 10 Sep 2008. Is that dll still available somewhere ? [03:04:56] <mru> mika_video: you can build it yourself [03:05:41] <mika_video> mru: is there anywhere documentation how to do that as a cross-compile, compiling under linux but producing dll for windows [03:06:41] <mika_video> Since if I have to use gcc to compile, I'd rather use gcc on linux than on windows. But how to get a special version of gcc that runs on linux but compiles windows apps and dll's [03:07:16] <mru> that's pretty far off-topic here [03:07:28] <mru> it's possible, that's all I know [03:08:06] <mika_video> Then just move chat about that into #ffmpeg instead [03:12:31] <mika_video> And, someone should write a web page explaining all three version numbers: a) the r15291 -style revision number. b) version number like FFmpeg 0.5.1 c) the version number returned by avformat_version() [03:12:50] <Dark_Shikari> svn version, ffmpeg version, and library version [03:12:52] <Dark_Shikari> what's so hard about that? [03:13:13] <mika_video> To understand what all thos numbers actually mean [03:13:20] <Dark_Shikari> 11:12 <@Dark_Shikari> svn version, ffmpeg version, and library version [03:15:37] <mika_video> is it the library version = returned by avformat_version(), that an app should check and refuse to run if MAJOR has cahnged but agree to run if MAJOR has stayed the same, even if both MINOR and MICRO have changed ? [03:16:04] <Dark_Shikari> MINOR is still an api change [03:16:07] <Dark_Shikari> MAJOR breaks compilation [03:16:10] <Dark_Shikari> MINOR breaks ABI [03:16:37] <mika_video> so only MICRO change is ok without recompiling the app ? [03:16:51] <Dark_Shikari> iirc, yes, that's the only one that's guaranteed [03:16:58] <mru> MINOR changes are backwards ABI compatible [03:17:46] <Dark_Shikari> ah ok [03:17:51] <Dark_Shikari> in that case it's just major that breaks abi [03:17:55] <mru> yes [03:18:01] <Dark_Shikari> wait, then why was the padding increase considered a minor bump? [03:18:03] <mru> minor is increased when new stuff is added [03:18:06] <mika_video> seems tha mru and Dark_Shikari disagree whether or not a MINOR library version change breaks binary compatibility between the library and an application using it. [03:18:15] <Dark_Shikari> mika_video: no, it seems that mru corrected Dark_Shikari [03:18:19] <Dark_Shikari> and stop talking about people in the third person [03:18:22] <Dark_Shikari> it's really fucking obnoxious [03:18:24] <mru> Dark_Shikari: the padding thing was a mistake [03:18:33] <Dark_Shikari> mru: yes, but even so, people commented that there should be a minor bump [03:18:49] <mru> people were mistaken I guess [03:19:20] <mru> it's not totally obvious [03:19:28] <mika_video> "MINOR changes are backwards ABI compatible" - so can I trust this one ? [03:19:30] <mru> it will still run and do the right thing most of the time [03:19:40] <mru> yes, unless we make a mistake [03:30:05] <peloverde> mru: I don't know why but gmail seems to be deciding that all mail coming from you is spam. I can easily fix it for me but others may be missing mail from you. [03:30:31] <mru> any indication why? [03:30:33] <ohsix> X-Spamassassin-Cooties: 100 [03:31:21] <mru> sending to myself works fine [03:38:05] <mru> and either way there's nothing I can do about it [03:38:19] <mru> if people use a crap mail service, so be it [03:41:34] <astrange> i keep getting spam with my own email in from: and gmail puts it all in the sent email label [04:50:04] <justlooking_> kshishkov> what's not pointless then? < perhaps someone capable of making a WMA-Pro Encoder for PS3 Media Server etc http://ps3mediaserver.org/forum/viewtopic.php?f=14&t=5916 [04:51:20] <Dark_Shikari> wmapro encoder? that's retarded [05:17:32] <CIA-92> ffmpeg: conrad * r22472 /trunk/libavformat/ (6 files): Add ff_ prefix to vorbis_comment [05:17:32] <CIA-92> ffmpeg: conrad * r22473 /trunk/libavformat/ (6 files): oggdec: Metadata is per-stream; don't merge multiple streams' together [05:17:32] <CIA-92> ffmpeg: conrad * r22474 /trunk/libavformat/ (oggparsevorbis.c oggdec.h): Const correctness for vorbis_comment [05:17:33] <CIA-92> ffmpeg: conrad * r22475 /trunk/libavformat/oggparseogm.c: oggdec: Read ogm metadata [05:17:33] <CIA-92> ffmpeg: conrad * r22476 /trunk/libavformat/oggparseogm.c: oggdec: Cosmetics [05:17:33] <CIA-92> ffmpeg: conrad * r22477 /trunk/libavformat/oggparsevorbis.c: oggdec: Parse ogm chapters [05:17:36] <CIA-92> ffmpeg: conrad * r22478 /trunk/libavformat/ (oggdec.c oggdec.h): [05:17:36] <CIA-92> ffmpeg: oggdec: Pass packets to header() until the stream is done with them [05:17:36] <CIA-92> ffmpeg: This fixes some old ogm files that had the 3rd vorbis header after a data [05:17:36] <CIA-92> ffmpeg: packet in another stream. This is invalid in ogg, but this change shouldn't [05:17:36] <CIA-92> ffmpeg: affect the behaviour of any valid file. [06:59:19] <pJok> mornings :) [06:59:29] <av500> gm [06:59:41] <kshishkov> goda morgnar [06:59:53] <elenril> o/ [07:01:01] <kshishkov> elentril: [message title="good morning" author="me" performer="me"] [07:02:20] <elenril> performer shouldn't be set when it's the same as author =p [07:03:06] <elenril> see also http://tvtropes.org/pmwiki/pmwiki.php/Main/DepartmentOfRedundancyDepartment [07:24:41] <pJok> author, artist and performer [07:52:29] <KotH> grüezi wohl [07:53:06] <kshishkov> shalom [07:56:23] <av500> slalom [07:56:35] * kshishkov is not into skiing [07:59:51] <justlooking_> Dark_Shikari> wmapro encoder? that's retarded < why ? , it serves a good purpose for the many 360 owners around the world, far more tthan say NUT does, sure its would be far better if Microsoft were to just update their firmware with better optimised and capable codecs adn containers but they wont and dont. [08:00:26] <kshishkov> IIRC, you can have mp3 in asf [08:00:38] <av500> yes [08:01:13] <av500> mpeg4 and mp3, it can be the new AVI :) [08:01:17] <justlooking_> streamable by the 360 ,No, or at least i cant get it playing with ps3ms. [08:01:35] <justlooking_> steamable and Playable by.... [08:02:14] <kshishkov> speaking what you are compehend I can not [08:03:24] <justlooking_> ohh i thought you were talking about using mp3 in asf for the 360, sorry.... [08:04:05] <kshishkov> I was [08:04:05] <av500> since the whole things is about mutlichannel, using mp3 would not solve that isse. [08:04:12] <kshishkov> ah [08:04:24] <kshishkov> AAC + XBMC then ;) [08:05:06] <justlooking_> chiped 360 and a PPC port of linux would be required for that. [08:06:07] <justlooking_> most people just want to use the broken DLNA client inside the thing. [08:06:21] <av500> kshishkov: so go write WMAPRO enc! [08:06:37] <astrange> does wmapro have a max bitrate? [08:06:50] <kshishkov> av500: oh yeah, go to Ukraine yourself! [08:06:53] <astrange> it's probably not hard to write a tolerable encoder if you just give up efficiency completely [08:07:09] <superdump> s/dlna/upnp/ [08:07:13] <superdump> unless something changed [08:11:11] <kshishkov> and the next thing somebody asks for WMV3 encoder [08:12:36] <KotH> oh, you're going to write a wmv3 encoder? [08:12:38] <KotH> cool! [08:12:39] <KotH> ;) [08:13:34] <kshishkov> no, you have Dark_Shikari for that [08:17:04] <justlooking_> that whitefrt guy on the link i posted above wrote wrapper for the "media foundation framework" as use by media center 7 for transcoding AVC/WMA-PRO 5:1.RTP exactly because ffmpeg doesnt do WMA-PRO encoding, its not portable but it works apparently kshishkov , but running XP ps3ms here u cant test it and say for sure. [08:20:04] <av500> well, transcoding to wmapro using window media api seems straightforward [08:29:10] <justlooking_> astrange> does wmapro have a max bitrate? < i dont know about a max limit , but MS restrict their VC-1/wmapro 5:1 to 15Mbit/s according to their website data , so they didnt even try and optimise their 360 codecs for their HW. [08:30:00] <pJok> optimization would mean that they have internal communication between departments [08:32:16] <superdump> i assume you want wmapro for multi-channel [08:32:31] <superdump> does the 360 not support any other multi-channel codecs? [08:33:14] <kshishkov> it's M$ thing [08:34:46] <justlooking_> yes, thts the ONLY reason anyone would want it OC, id much prefer better 3x3gig PPC optimised codecs/containers in the next firmware update, but MS wont do that, so nect bets thing, find ways to improve what we have. [08:34:55] <justlooking_> next best thing. [08:35:59] <superdump> hmm [08:36:14] <superdump> so it doesn't support multi-channel LPCM? [08:37:30] <kshishkov> superdump: http://www.engrish.com//wp-content/uploads/2010/03/2rd-floor.jpg [08:38:21] <justlooking_> AVC/AAC2:1 10Mbit/s or VC1/WMA-PRO5:1 15Mbit/s ,thats about it until whitefrt found it would also do RTP AVC/WMA-PRO5:1 [08:39:54] <justlooking_> in a round about and not portable fasion OC. [08:42:43] <superdump> kshishkov: i think the l/r swap in pronunciation is quite interesting [08:42:52] <superdump> but i was speaking with a guy from hong kong a few weeks ago [08:43:00] <superdump> he said he'd been learning english for 10 years or something [08:43:13] <superdump> but in the classes, they never speak english to learn pronunciation [08:43:19] <superdump> they just learn grammar [08:43:58] <superdump> maybe i'm weird but one of the first things i found myself doing in sweden was learning the sound and rhythm of the language [08:44:30] <kshishkov> ja, svenska Ã€r rolig [08:45:15] <wbs> superdump: how long have you been in sweden? [08:46:26] <pJok> svenska är rolig [08:46:29] <kshishkov> longer than me at any rate [08:46:53] <pJok> om du inte pratar svenska bra som jag, då är det roligt [08:48:26] <kshishkov> I've heard people speaking in DSB train once, it's like they spoke Swedish worse than me [08:48:47] <superdump> wbs: i've spent some months there since last year [08:48:54] <superdump> back in the uk for a couple of weeks [08:49:00] <superdump> but i'm moving to stockholm when i return [08:49:16] <wbs> ah, I see [08:49:43] <kshishkov> wbs: and I've been to Finland for ~1.5 days [08:50:09] <wbs> kshishkov: grattis ;-) [08:50:40] <justlooking_> kshishkov> what's not pointless then? < thats the Only reason i posted the WMA-PRO5:1 thing in the first place, but i take it its to hard or fun and you dont want to, so fair enough, i know my typing skills are bad ,but when people are more interested in talking about engrish its time to stop asking. [08:50:46] <superdump> i was in finland for a couple of days too [08:50:50] * kshishkov wonders why Finns have town named after the holiest Ukrainian food while Ukrainians don't [08:51:12] <wbs> kshishkov: which one is that? [08:51:45] <kshishkov> justlooking_: well, we are too lazy to do that, and some of us have short attention span. [08:51:49] <kshishkov> wbs: Salo [08:52:02] <wbs> kshishkov: ah, interesting. :-) [08:52:11] <wbs> kshishkov: I actually worked in Salo for 1,5 years [08:52:46] <kshishkov> and I only passed it on a way from Ãbo to Helsingfors [08:53:02] <kshishkov> (or from Turku to Helsinki, don't remember) [08:53:29] <wbs> i prefer åbo and helsingfors :-) [08:54:03] <kshishkov> well, those names are usually surrounded by the words I understand better ;) [08:54:24] <pJok> kshishkov, the danes in the dsbfirst trains usually speak very bad swedish [08:55:02] <pJok> kshishkov, but then again, sometimes they speak swanish on purpose so they don't have to say the same thing twice [08:55:16] <kshishkov> pJok: it was Fredericia-Copenhagen IC3 but I suspect they spoke Danish [08:55:45] <kshishkov> pJok: and not even intended to speak Swedish [08:56:15] <pJok> kshishkov, thats when they speak danish [08:56:30] <pJok> IC3 trains only have announcements in danish and sometimes english [08:57:36] <kshishkov> denglish is more likely [08:58:11] <kshishkov> it's just Danish sounds to me like badly maimed Swedish, written form is even more so [08:58:17] <pJok> it is [08:58:36] <pJok> but then again, to me written swedish just simultaneously translates to danish when i read it [08:58:45] <pJok> i dont do that with german and english [09:01:47] <kshishkov> looks like Swedish loanwords come from French for better sounding and from English while Danish borrowed from German [09:02:26] <pJok> actually swedish, danish, norwegian, farose and icelandic are all the same base language [09:03:04] <kshishkov> yes, Norsk [09:03:22] <pJok> actually icelandic and farose are closer to the original language [09:03:55] <pJok> seeing as they are more isolated, so less influence from the outside world [09:03:55] <kshishkov> yes, being isolated and whatever [09:04:25] <pJok> also remember that denmark occupied a lot of england [09:04:33] <pJok> and germany [09:04:51] <pJok> so the influence is a lot bigger from those languages [09:04:52] * kshishkov has never heard of Hamlet from Helsingo/r [09:06:02] <pJok> its still funny that the "swedish mentality" about denmark is that denmark is just another country while the skånska and danish mentality is that skåne and sjælland are just the same region [09:06:30] <pJok> but then again, copenhagen is next to skåne while stockholm is nearly 600km away [09:07:10] <kshishkov> yes, Dnes tried to move their capital to the furthest point from the center of Denmark indeed [09:08:34] <pJok> i dont even notice that i live in sweden and work in denmark [09:08:51] <av500> mru: ping [09:09:07] <av500> OBJS-$(ARCH_ARM) += arm/h264pred_init_arm.o [09:09:25] <kshishkov> pJok: lucky you, here you'll be constantly reminded in what Ukraine you live :( [09:09:33] <av500> NEON-OBJS-$(CONFIG_H264_DECODER) += arm/h264pred_neon.o [09:09:54] <av500> if you build for ARM but not H264, it fails [09:10:35] <kshishkov> disable SVQ3 and RV3/4 as well and it should work [09:10:53] <av500> they are [09:11:09] <av500> I have no video decoder enabled, but I build for arm [09:11:15] <av500> and neon [09:11:51] <av500> so h264pred_init_arm.c tries to init the neon stuff for h264 [09:12:03] <pJok> kshishkov, maybe it gets better in about 200 years? [09:12:32] <kshishkov> pJok: unlikely [09:15:37] <pJok> kshishkov, you are so optimistic :) [09:16:01] <pJok> but then again, i've never been to the ukraine so i can't really judge on how things are [09:16:25] <pJok> i've only been to the czech republic and the baltics [09:17:01] <kshishkov> those are totally different [09:18:05] <av500> kshishkov: http://pastebin.com/2HsjrxWk [09:18:09] <pJok> those are the only former semi-russian countries i have been to [09:18:19] <kshishkov> Kiev (which differs from the rest of Ukraine though) is like Copenhagen with less maintainance of buildings and more drunks [09:18:54] <pJok> so a bit like prague then [09:19:02] <pJok> and riga [09:19:38] <kshishkov> av500: I told you that code is also used by SVQ3 and RV3/4 decoders, CONFIG_H264_DECODER may be not enough [09:20:03] <av500> right [09:20:13] <av500> I would rather solve it in the Makefile [09:20:36] <kshishkov> pJok: Riga was always a piece of Europe under Soviet occupation to me and the only common thing we have with Praha is their old trams ;) [09:24:10] <pJok> kshishkov, true... and the baltics have both been danish and swedish before they were russian [09:24:52] <kshishkov> pJok: Russians even illegally built their future capital on Swedish land [09:25:48] <pJok> well, borders back then were blurry [09:26:24] <kshishkov> pJok: this may be considered a typical view here - http://commons.wikimedia.org/wiki/File:John_the_Baptist_church.jpg [09:27:10] <pJok> not an all bad view [09:27:31] <kshishkov> that's because you don't see all that dirt [09:27:44] <pJok> its not a street view [09:27:50] <pJok> i imagine all the dirt being there [09:37:36] <av500> kshishkov: but then it is still wrong as arm/h264pred_neon.o is only added for CONFIG_H264_DECODER, not for SVQ3 or RV... [09:38:53] <kshishkov> looks like somebody was no too eager to have faster RealVideo decoding on ARM :) [09:39:16] <av500> I have it on the DSP :) [09:40:10] <kshishkov> have what? [09:40:53] <av500> RV [09:41:14] <kshishkov> how much buffering DSP interface require? [09:41:22] <av500> buffering? [09:42:36] <kshishkov> yes, it's Real it must have buffering [09:42:48] <av500> :) [09:42:53] <av500> we did not license that part [09:44:08] <av500> kshishkov: http://pastebin.com/d8wCdrar [09:44:24] <av500> that would be needed, no? [09:45:13] <kshishkov> av500: seems reasonable [09:45:25] <superdump> does someone have a copy of 14496-3 subpart 1 [09:45:27] <superdump> ? [09:46:03] <av500> http://www.filestube.com/i/iso+iec+14496+3+pdf [09:46:46] <av500> ftp://ftp.tnt.uni-hannover.de/pub/MPEG/audio/mpeg4/documents/w2203/w2203.pdf [09:47:12] <kshishkov> it may be a good thing to have all closed standards bought for FFmpeg devs by our NGO [09:47:58] <bilboed-tp> kshishkov, that's gonna be ONE BIG BILL [09:48:49] <superdump> av500: what's the user/pass for that? [09:48:53] <kshishkov> bilboed-tp, yes and since it's in Swiss Franks we'll leave it to KotH to pay :) [09:49:08] <bilboed-tp> rofl [09:49:24] <av500> superdump: for the ftp link? [09:49:28] <superdump> yes [09:49:35] <av500> worked for me like that (in a browser) [09:49:47] <av500> but the ftp seems to be a draft [09:49:59] <superdump> as long as it's readable, that's ok [09:50:29] <av500> I could just click on it here: ftp://ftp.tnt.uni-hannover.de/pub/MPEG/audio/mpeg4/documents/w2203/ [09:50:50] <av500> I also have the real one if you want it [09:52:39] <superdump> i got that pdf [09:52:43] <superdump> seems rather old [09:53:03] <av500> wait a sec [09:55:54] * KotH notes, that he should revive that documents folder on mphq [10:01:00] <KotH> lu_zero: as i said, deside on what you want and let me know. i'll take care of the rest [10:02:24] <kshishkov> M$ IIS :) [11:03:55] <elenril> Dark_Shikari: so our resident theoretical guru said that infalling observer 1)_will_ fall into the singularity in his finite time (and there _will_ be a singularity) [11:04:15] <elenril> and 2) he won't see any radiation in his frame [11:04:52] <elenril> for him the black hole doesn't evaporate [11:05:15] <mru> what happens if schrÃ¶dinger's cat falls into a black hole? [11:05:41] <iive> it dies for sure. [11:05:53] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/RocksFallEveryoneDies [11:09:19] <kshishkov> well, no radiation = nothing to see = useless observer = very short paper [11:09:36] <elenril> i meant no hawking radiation [11:10:23] <kshishkov> for large black holes yes [11:10:32] <elenril> yes what [11:10:42] <justlooking_> so ask your "resident theoretical guru" explain why is it that any giben mass of clusters or galaxies is always directly proportional to the mass of the central black hole!, [11:10:45] <kshishkov> no Hawking radiation [11:11:05] <justlooking_> giben/given [11:11:47] <kshishkov> justlooking_: maybe because that's 90% of mass :) [11:12:28] <elenril> kshishkov: no, for any black hole [11:12:42] <kshishkov> elenril: still, it looks like that falling observer has actually little to observe [11:13:10] <kshishkov> elenril: so you just don't believe in it? [11:14:10] <justlooking_> your forgettinf about so called dark flow and dark matter(who comes up with these names), thats said to be 75% of all mass inthe universe in current thinking. [11:14:25] <elenril> no, only the falling object doesn't see any radiation [11:14:39] <elenril> the rest of the universe will see it [11:16:01] <kshishkov> so falling object will be bored to death when it reaches black hole :) [11:17:56] <kshishkov> mate! [11:18:18] <kshishkov> any barrel worth looking at? [11:27:35] <av500> mru: thx [12:26:46] <CIA-92> ffmpeg: aurel * r22479 /trunk/libavcodec/Makefile: fix compilation with --disable-everything --enable-decoder=twinvq [12:27:17] * elenril pokes Honoome [12:27:36] <CIA-92> ffmpeg: aurel * r22480 /trunk/libavcodec/Makefile: fix compilation with --disable-everything --enable-muxer=mpegts [12:28:21] * KotH pokes elenril [12:28:54] <Honoome> elenril: yeah? [12:49:51] <gthreepwood> Hi, I'm having trouble maintaining debug symbols during compile. I'm configuring using the arguments: --enable-debug=1 --disable-optimizations --disable-asm --disable-stripping. I can get function names in a backtrace but not source files or lines. [12:56:55] <gthreepwood> nvm, --enable-debug=1 was erroneous [13:04:31] <CIA-92> ffmpeg: ramiro * r22481 /trunk/configure: Document --disable-everything in configure --help. [13:15:30] <elenril> Honoome: maybe you should ping your patch [13:20:10] <Honoome> elenril: is baptiste around now? ^^ [13:21:45] <elenril> i think he committed some things yesterday [13:25:42] <kierank> can ida pro give you access to the memory map like ollydbg can? [13:46:39] <mru> yay, all the fate systems are back online [13:47:17] <kshishkov> good [13:47:24] <mru> and ia64 is failing [13:47:33] <kshishkov> not so good [13:47:36] <av500> is that news? [13:48:23] <mru> it's our old friend: relocation truncated to fit: GPREL22 against `.bss' [13:51:45] <kshishkov> any fix except random code twiddling? [13:52:22] <mru> fixing gcc? [13:52:35] <kshishkov> not an option [13:56:28] <av500> fixing ia64? [13:56:38] <kshishkov> it came pre-broken [13:57:20] <janneg> ignore it, intel seems to do it too [13:57:33] <Kovensky> at least gcc doesn't run out of registers [13:58:50] <kshishkov> http://en.wikipedia.org/wiki/Itanic says it has 128 regs, it's hard to run out of all of them even for GCC [13:59:07] <mru> gcc often performs worse with more registers available [13:59:36] <kshishkov> first four words are enough [15:13:05] <CIA-92> ffmpeg: michael * r22482 /trunk/ffplay.c: Print skip_frames variable. [15:19:00] <gangil> hi ,I want to be a GSOC student with ffmpeg , how can I know which qualification tasks are open ? [15:21:31] <Dark_Shikari> most of them [15:22:38] <CIA-92> ffmpeg: michael * r22483 /trunk/libavcodec/h264.c: [15:22:38] <CIA-92> ffmpeg: Always reset slice_table. [15:22:38] <CIA-92> ffmpeg: Previously, the area of a lost slice would be left at the slice number of the previous [15:22:38] <CIA-92> ffmpeg: frame which could occasionally match the number of the next slice and thus a non existing [15:22:38] <CIA-92> ffmpeg: slice could have been used for prediction leading to additional decoding errors in otherwise [15:22:39] <CIA-92> ffmpeg: undamaged slices. [15:23:07] <kshishkov> gangil: claimed tasks are marked as such in our wiki [15:23:16] <Dark_Shikari> yay, here comes michael's improvements to error concealment [15:24:16] <CIA-92> ffmpeg: michael * r22484 /trunk/libavcodec/h264.c: Fix indention [15:24:31] <av500> kshishkov: wiki missed the WMAPRO encoder qualification task :) [15:25:23] <kshishkov> av500: so do we [15:35:33] <BBB> hello, my flamy fellow devs :) [15:35:38] <kshishkov> BBB: do you want to write WMApro encoder? [15:35:43] <BBB> no [15:35:54] <BBB> I'd rather encode to vorbis than to wmapro [15:35:54] <Dark_Shikari> why in the world would anyone want to do that [15:35:59] <Dark_Shikari> wmapro is just a ripoff of aac [15:36:03] <BBB> that too [15:36:04] <BBB> anyway [15:36:05] <Dark_Shikari> might as well write a good aac encoder [15:36:07] <Dark_Shikari> and aac is more useful [15:36:10] <BBB> I'd like to focus on RE'ing new decoders [15:36:15] <BBB> decoding is useful [15:36:18] <Dark_Shikari> WVP2 [15:36:23] <BBB> encoding is like submitting your soul to the devil [15:36:27] <BBB> yes, WVP2 is high on my list [15:36:31] <BBB> I'd like to learn video, still [15:36:37] <kshishkov> Dark_Shikari: some losers with ybox and no desire to install something like XBMC [15:36:46] <Dark_Shikari> kshishkov: xbox supports aac [15:36:47] <Dark_Shikari> and ac3 [15:37:04] <kshishkov> not multichannel [15:37:15] <Dark_Shikari> it supports multichannel ac3 [15:37:42] <kshishkov> whatever, someone asked for it this morning [15:37:51] <Dark_Shikari> I saw, and it's still stupid [15:38:10] <Dark_Shikari> writing encoders for proprietary formats should be very carefully considered [15:38:24] <kshishkov> and rejected freely :) [15:38:29] <Dark_Shikari> yes, exactly [15:38:34] <Dark_Shikari> because writing an encoder can be a _Bad_ thing [15:38:45] <peloverde> we have an alac encoder [15:38:56] <Dark_Shikari> yeah, but that made sense because: [15:39:01] <mru> alac isn't a terrible format [15:39:02] <Dark_Shikari> a) nobody will ever use alac in place of flac when they don't need to [15:39:09] <mru> it's quite good actually [15:39:11] <Dark_Shikari> b) ipods will never support flac [15:39:20] <Dark_Shikari> c) we did a better job than apple so lol [15:39:26] <Dark_Shikari> d) it was easy (shares a lot of flac code) [15:39:31] <peloverde> e) stuff doesn't get "stuck" in a lossess format [15:39:35] <Dark_Shikari> And yeah, that [15:40:07] <av500> f) lossless does not need an elaborate psych model, no? [15:40:37] <kshishkov> av500: along with rate control and other mindboggling stuff [15:40:47] <Dark_Shikari> >implying ratecontrol is hard [15:41:15] <kshishkov> ratecontrol with proper bit allocation [15:41:29] <Dark_Shikari> ratecontrol doesn't allocate bits, it chooses quantizers [15:41:49] <Dark_Shikari> bit allocation is a consequence of ratecontrol, not a a responsibility [15:42:26] <kshishkov> then why FFmpeg does not have generic mpegvideo-independent rate control yet? [15:42:47] <peloverde> but sometimes there are external requirements on bit allocation [15:42:59] <Dark_Shikari> kshishkov: for the same reason it doesn't have a generic psymodel [15:43:07] <Dark_Shikari> also, mpegvideo has the VBV model to deal with [15:43:10] <Dark_Shikari> which is the hard part [15:43:17] <Dark_Shikari> not sure how that comes into play in audio [15:43:26] <Dark_Shikari> also, audio generally has less rate variation than video [15:43:30] <Dark_Shikari> and the quantizer scale is different [15:43:50] <BBB> guys [15:43:54] <BBB> you're forgetting the whole point [15:43:58] <BBB> I know nothing about audio [15:44:00] <Dark_Shikari> no, I have a sharp pencil right here [15:44:00] <BBB> let alone video [15:44:05] <BBB> I know the bitstream format [15:44:07] <BBB> that's about it [15:44:08] <Dark_Shikari> Then learn [15:44:20] <BBB> I should not focus on encoding a crappy format with a crappy encoder [15:44:24] <BBB> it's wrong, double wrong [15:44:35] <BBB> I should focus on decoding, which is easy, or encoding with good encoders into good formats [15:44:35] <kshishkov> BBB: I did, so what? [15:44:43] <BBB> kshishkov: dunno ;) [15:44:50] <BBB> anyway, no, I won't write a wmapro encoder [15:44:57] <BBB> but if someone pays me $100k I'll consider it [15:45:10] <kshishkov> BBB: you'll get many thanks from Diego if you write VoxWare decoder [15:45:25] <BBB> I thought you wanted me to do intel audio 4? [15:45:38] <Dark_Shikari> Do wvp2 [15:46:02] <kshishkov> there was only intel audio 2 [15:46:35] <kshishkov> and yes, someone should do wvp2 eventually [15:46:48] <BBB> Dark_Shikari: how much for wvp2? [15:46:59] <BBB> ;) [15:48:23] <kshishkov> BBB: probably a free Facebook account ;) [15:52:26] <BBB> lol :) [15:52:58] <bilboed-tp> only if in mint condition [15:53:18] <av500> I thought a free gmail acount soon, no? [15:54:47] <BBB> facebook was sponsored by MS [15:54:52] <BBB> so more likely a free MS Live account [15:54:56] <BBB> or did they rename it again? [15:55:09] <BBB> HotMail 4.0 [15:55:44] <kshishkov> a reward from M$ for REing M$ codec? 512 years in jail more likely [15:57:27] <Dark_Shikari> MS would _loooove_ an open source VC-1 encoder [15:57:51] <Dark_Shikari> 'course they would have liked it more 5 years ago when it was actually relevant [16:00:12] <peloverde> then maybe they should open source their encoder [16:02:10] <Dark_Shikari> >microsoft [16:02:12] <Dark_Shikari> >open sourcing things [16:02:13] <Dark_Shikari> ahhaha [16:02:43] <av500> pwszzstrLicenceDetails [16:02:49] <kshishkov> but they do it [16:05:25] <peloverde> they shouldn't be dissatisfied with the lack of an oss encoder if they aren't willing to help [16:07:58] <kshishkov> we almost got vp6 encoder though :( [16:13:22] <BBB> kshishkov: do you remember how in ida I get rid of this balloon iew and go back to regular disassembly view? [16:13:40] <BBB> I keep getting stuck in the arrow-view instead of disassembly view, and don't know how to get out of it [16:13:40] <kshishkov> right-click menu -> "text view" [16:13:50] <BBB> ah, that was it [16:13:58] <BBB> you are my hero [16:14:03] <kshishkov> :) [16:14:19] * DonDiego hopes he is nobody's hero... [16:14:46] <kshishkov> not married, unemployed, has not got degree, third-world country citizen is your hero? [16:15:11] <BBB> absolutely [16:15:39] <DonDiego> who *does* have a degree around here? :) [16:15:59] <BBB> kshishkov has a PhD right? [16:16:08] <kshishkov> nope [16:17:00] <kshishkov> it would require me anouther year of useless postgrad work, writing useless thesis and three years of slavery afterwards [16:18:39] <BBB> hm... [16:18:46] <BBB> I'll get a PhD in a couple of months, hopefully [16:21:22] <av500> that means, soon you are the most qualified! :) [16:22:47] <Dark_Shikari> um, I almost have a bachelor's... [16:22:48] <Dark_Shikari> ;) [16:23:02] <BBB> overqualified, really [16:23:07] <BBB> it doesn't take a PhD to RE codecs [16:23:12] <BBB> in fact, anyone can do it [16:23:24] <BBB> a PhD is just a sad excuse for companies to not hire me because they'll think I'm more expensive [16:23:52] <av500> Phd in biology -> zoo keeper? [16:24:19] <DonDiego> BBB: try google, they hire a lot of phds [16:24:39] <BBB> my sis-in-law works at google [16:24:43] <BBB> not a happy place, might I say [16:25:00] <BBB> it might've been great 10 years ago, but right now I don't see good vibes [16:27:56] <kshishkov> BBB: I got my master degree during REing RV4 [16:31:28] <DonDiego> go figure, i thought google was a nice workplace from all i heard.. [16:31:52] <kshishkov> it's mostly rumours what you hear anyway [16:32:57] <kshishkov> a long time ago Bell Labs was an incrediable place to work at [16:36:02] <BBB> kshishkov: well, she works in mobile, and basically they work 6hrs/day for seriously long periods of time, and half of the projects get cut then [16:36:08] <BBB> it's very, very competitive [16:36:19] <BBB> 16hrs/day, not 6 [16:38:32] <superdump> i was going to say, 6hrs a day seems nice :) [16:38:37] <KotH> does anyone know where one could get the exact mechanical dimensions of a 3.5" harddrive (aka a mechanical drawing) ? [16:38:50] <kshishkov> google.com [16:39:29] <KotH> i already googled [16:39:33] <KotH> didnt find anything [16:40:38] <av500> your hdd drawer and a ruler? [16:41:19] * kshishkov has FDD drive lying around [16:44:41] <KotH> av500: we need it for production, so we need to have more or less reliable data [16:52:28] <DonDiego> Yuvi: i assigned you a bunch of bugs, i hope you don't mind.. [16:55:05] <DonDiego> peloverde: did i already pour kind words of thanks, appreciation and professional esteem over you? [16:55:13] <DonDiego> (for sbr support in aac) [16:55:42] <peloverde> It's possible, I don't remember :) [16:55:53] <DonDiego> ok, remind me to do it some day [16:56:00] <DonDiego> ;-p [16:56:14] * DonDiego hails peloverde [16:56:23] * DonDiego hails peloverde some more [16:56:23] <peloverde> thanks [16:56:48] * DonDiego hails peloverde until his arms get tired and his throat is sore [16:57:08] <DonDiego> i'm superhappy :) [16:57:10] <kshishkov> you'll die praising him when he makes ffaacenc usable [16:57:36] <Dark_Shikari> We should set up a donation fund for ffaacenc [16:57:38] <Dark_Shikari> seriosuly [16:57:41] <Dark_Shikari> I know people who would donate [16:57:44] <peloverde> thanks again, so know that sbr landed what's the status on 0.6 [16:57:52] <Dark_Shikari> my idea: make it a bounty fund [16:58:07] <Dark_Shikari> anyone who can make ffaacenc beat LAME in a hydrogenaudio test at 96kbps [16:58:11] <Dark_Shikari> gets all the money [16:58:38] <DonDiego> peloverde: that was a big bump in the road for 0.6 [16:58:50] <elenril> now to merge -mt ;) [16:58:52] <DonDiego> now it depends on Yuvi and his theora and ogg work [16:59:01] <DonDiego> elenril: if only there was a patch :( [16:59:09] <DonDiego> astrange: how about proposing it? [16:59:15] <Dark_Shikari> seriously, merge mt [16:59:19] <Dark_Shikari> this will make everyone more awesome [16:59:22] <DonDiego> yes, seriously [16:59:29] <Dark_Shikari> the problem right now is that it's a maintenance disaster [16:59:33] <Dark_Shikari> astrange has to keep updating his fork [16:59:50] <DonDiego> well, propose it and have everybody review it [17:00:02] <DonDiego> this stuff will generate interest just like aac sbr [17:00:11] <DonDiego> not only michael reviewed that [17:00:13] <CIA-92> ffmpeg: michael * r22485 /trunk/libavcodec/error_resilience.c: Fix guess_mv() so that it works correctly with 4x4 MV blocks. [17:00:34] <DonDiego> Yuvi: can you give me a status update about your theora and ogg work? [17:00:50] <av500> work on making it go away? [17:01:24] <DonDiego> lol, no working on making it rock :) [17:03:44] <DonDiego> Yuvi: i understood r22463 to fix seeking in ogg theora files, but it did not in my tests with mplayer.. [17:03:54] <Dark_Shikari> mplayer doesn't use lavf [17:04:04] <Dark_Shikari> iirc [17:04:12] <DonDiego> it does if you tell it to :) [17:04:12] <mru> it can do [17:04:34] <DonDiego> and depending on the container lavf is the default, mov/mp4 for example [17:07:06] <Kovensky> <@DonDiego> lol, no working on making it rock :) <-- you expect him to make ogg rock? o_O [17:07:53] <mru> some people believe in miracles [17:08:18] <kshishkov> DonDiego: someone should bury default MPlayer demuxer - it spends a minute trying to guess MPEG format out of some file supported by lavf (usually it's TTA or Bink) [17:08:29] <jai> the fsf already has a PlayOgg campaign, start a FlayOgg to keep things even [17:08:30] <DonDiego> i have high hopes of him making the ogg *support* within ffmpeg rock [17:08:32] <mika_video> is there either a rule or a list, how to convert release numbers like r22485 into either library version numbers or nightly snapshot dates ? [17:08:48] <DonDiego> kshishkov: give me some examples [17:09:03] <DonDiego> kshishkov: it should just be a matter of switching defaults for some files [17:09:07] <KotH> mika_video: yes, using svn and some bash magic [17:09:11] <Kovensky> mika_video: checkout revision, extract version number from headers? o_O [17:09:50] <kshishkov> DonDiego: playing any large TTA or Bink file over NFS [17:09:56] <kshishkov> on a PowerPC [17:09:59] <DonDiego> not locally? [17:10:44] <kshishkov> with TTA it's even locally [17:11:43] <DonDiego> try overriding the demuxer by file extension [17:11:49] <DonDiego> for tta files [17:12:04] <DonDiego> if that works, commit [17:12:11] <kshishkov> why not make MPlayer detect it with lavf first? [17:12:48] <DonDiego> that's what i'm saying [17:13:03] <kshishkov> it=everything, not just some exceptions [17:13:35] <DonDiego> discuss that on the ml [17:15:12] <Kovensky> <@kshishkov> why not make MPlayer detect it with lavf first? <-- mplayer first tries with lavf, but only sticks with it for the formats on the preferred list [17:15:16] <Kovensky> then it tries everything else, and if all else fails, lavf again ._. [17:17:54] <DonDiego> peloverde: what's the status of aac and sbr? any known bugs or regressions? [17:22:41] <BBB> submit -mt [17:22:49] <BBB> I'll do initial reviews so michael doesn't have to [17:23:05] <BBB> review will say: "awesome! please commit!" [17:24:06] <Kovensky> lol [17:28:52] <CIA-92> ffmpeg: diego * r22486 /trunk/ (libavdevice/bktr.c configure): (log message trimmed) [17:28:52] <CIA-92> ffmpeg: Add _XOPEN_SOURCE=600 to CPPFLAGS on NetBSD. [17:28:52] <CIA-92> ffmpeg: This make NetBSD compile out of the box at the cost of a hack, but a [17:28:52] <CIA-92> ffmpeg: locally contained one that is preferable to the one used in the wild. [17:28:52] <CIA-92> ffmpeg: Currently the NetBSD FATE box adds -D_NETBSD_SOURCE to CPPFLAGS to work [17:28:53] <CIA-92> ffmpeg: around broken system headers. Since it is unlikely for NetBSD to fix their [17:28:54] <CIA-92> ffmpeg: headers, it is better to use a standard flag instead of a system-specific one. [17:30:09] <CIA-92> ffmpeg: diego * r22487 /trunk/libavdevice/bktr.c: [17:30:09] <CIA-92> ffmpeg: Replace BSD-specific integer types by their POSIX equivalents. [17:30:09] <CIA-92> ffmpeg: Tested to work by Michael Kostylev on the NetBSD FATE box. [17:30:20] <BBB> DonDiego: ... and add av_cold to init ... [17:30:27] <BBB> (if you can modify the commit msg) [17:30:49] <DonDiego> oh, crud [17:30:53] <DonDiego> that slipped in.. [17:31:05] <DonDiego> i love being able to edit commit messages.. [17:33:48] <peloverde> DonDiego: no known bugs or regressions [17:34:12] <DonDiego> ok, cool [17:34:18] <BBB> TY [17:34:23] <DonDiego> ty? [17:34:29] <peloverde> There were a few but they've all been fixed [17:34:40] <DonDiego> excellent [17:34:43] * DonDiego pets peloverde [17:35:02] <DonDiego> don't you dare buy drinks at the next fosdem beer event [17:35:15] <BBB> ty=thankyou [17:35:52] <DonDiego> i'll make sure you get your orders [17:36:08] <DonDiego> served to you by my humble self [17:36:40] <DonDiego> or others that wish to join me in providing your liquid supply.. [17:36:59] <peloverde> I'm sure by next fosdem there will be a whole new crowd of FFmpeg heroes [17:37:27] <DonDiego> we'll see :) [17:37:55] <DonDiego> i'm not sure i will have occasion to buy you beer before next fosdem.. [17:38:01] <av500> there will be kshishkov WMAPRO encoder :) [17:38:29] <DonDiego> av500: btw, did i see a patch from you being committed? [17:41:01] <av500> yes [17:41:10] <av500> a wee tiny one [17:41:28] <DonDiego> leave the channel [17:41:32] <DonDiego> immediately! [17:41:34] <DonDiego> ;) [17:41:40] <DonDiego> but rejoin right away [17:42:27] <DonDiego> there you are :) [17:42:29] <elenril> av500++ [17:42:46] * av500 blushes [17:43:13] <DonDiego> now keep those patches coming :) [17:44:21] <av500> I already have a love-hate relationship with the asf muxer... :) [17:44:44] <elenril> chapters muxing soon? [17:45:13] <av500> elenril: I'd love to have the negative ts issue resolved 1st [17:46:06] <av500> and I also want to fix the complaints that M$ ASF viewer has with the files we generate [17:46:15] <BBB> Vitor1001: btw, since all other filters are finished now, have you had any thoughts about the frequency domain filter in wmavoice yet? If not, I'll start working on that (will require tons of reading) [17:48:55] <elenril> av500: doesn't the patch i sent today fix it? [17:49:17] <av500> err which one [17:49:25] <elenril> riff: don't pad extradata when writing ASF [17:51:24] <av500> no, not related [17:51:49] <elenril> then what is the issue? [17:52:29] <av500> asf viewer complains that some packets are marked as multipayload, but have only 1 payload [17:52:39] <elenril> oh [17:52:42] <av500> I think this is a minor thing, but you never know with M$ SW (WMP) [17:53:00] <elenril> true [17:53:09] <av500> also, atm it muxes negative timestamps which cannot be stored in ASF [17:53:25] <av500> hence my quest to not have negative ts... [18:03:52] <Dark_Shikari> too many fucking companies holy shit [18:04:03] <Dark_Shikari> I just got the 9th company wanting to potentially hire me for the summer [18:04:12] <Dark_Shikari> the rate is increasing [18:04:16] <elenril> they got hit with a clue stick? [18:04:34] <peloverde> Even I found work, the economy really is turning around [18:04:47] <Dark_Shikari> autodesk [18:05:04] <Dark_Shikari> so now the total list of companies that have inquired/offered/whatever relating to jobs: [18:05:13] <kshishkov> Dark_Shikari: make your new contribution appear under name of, say, Garrett Jason-Glaser ;) [18:05:24] <Dark_Shikari> gaikai, otoy, zencoder, google, avail, green hills software, autodesk, skype, quallcomm [18:05:31] <Dark_Shikari> the fuck is with this. [18:06:37] <elenril> 1) found Dark Shikari Inc [18:06:42] <elenril> 2) accept all the jobs [18:06:46] <elenril> 3) ??? [18:07:08] <kshishkov> 3) outsource them to Jai [18:07:11] <kshishkov> 5) profit! [18:07:13] <Dark_Shikari> lol [18:07:17] <Dark_Shikari> these are all onsite jobs though :/ [18:07:20] <Dark_Shikari> harder to outsource [18:07:52] <kshishkov> mail order Jai and disguise him a bit, problem solved [18:08:23] <kierank> is .ua not considered far enough to be called "outsourced" yet ;) [18:08:34] <bilboed-tp> find minions, accept all contracts that offer IRC connectivity, send out minions as yourself [18:08:35] <bilboed-tp> done [18:09:44] <kshishkov> kierank: it is, once I had to work disguised as another man in a project outsourced in the fourth grade [18:10:04] <kierank> "Dave from AT&T" ? [18:10:17] <kshishkov> in the fourth grade = one company outsourcing it to another company which outsourced it again, continue [18:10:21] <kshishkov> no [18:10:23] <kierank> llol [18:10:42] <kshishkov> it was for some British company at the end [18:11:09] <kierank> lots of british companies are going to eastern europe now [18:12:43] <kshishkov> that was 3-4 years ago [18:13:10] <DonDiego> ffplay keeps crashing for me on os x, can anybody confirm this behavior? [18:13:32] <DonDiego> also, does anybody know how to turn off the crash report notifications to apple (for ffplay) [18:13:32] <kshishkov> probably not [18:13:38] <peloverde> ffplay crashes or hangs for me just about everywhere [18:14:15] <DonDiego> i cannot really make any sensible tests here.. :-( [18:14:27] <av500> gdb ffplay? [18:14:36] <gangil> hi , is there any starting material that can get me started over with the code base ? (just wanted to confirm) [18:15:10] <av500> grab a random bug and try to fit it [18:15:34] <DonDiego> read the developer docs and try the multimedia wiki [18:16:14] <peloverde> gangil: is there something particular you are interested in? [18:16:18] <DonDiego> btw, we need some benchmarking instructions in the dev docs [18:16:32] <DonDiego> i'm never sure how exactly to do them [18:16:58] <kshishkov> ffmpeg -benchmark -i infile -f null [18:16:59] <peloverde> we also need to update MOOBEX [18:17:47] <gangil> peloverde: basically , I am trying to get started with the code base , as I want to participate with ffmpeg in GSOC [18:20:18] <peloverde> codecs are in libavcodec/, (de)muxers are in libavformat/, common code is in libavutil or libavcodec, files are generally named by format name, for things that are shared you can find those by looking at something that uses them [18:20:47] <DonDiego> gangil: check out the multimedia wiki, there are a few short howtos there [18:20:57] <peloverde> documentation is at http://ffmpeg.org/documentation.html and in wiki.multimedia.cx [18:21:06] <DonDiego> http://wiki.multimedia.cx/ there is a category named "ffmpeg", look at that [18:39:00] <sancode> hello [18:42:58] <BBB> gangil: whch project will you participate in? [18:43:43] <gangil> havent decided yet , but I like the organization , as I want to work on codecs etc. [18:44:04] <gangil> I was a GSOC student last year [18:44:08] <gangil> with tux4kids [18:44:28] <BBB> ok [18:44:34] * gangil successfully completed that [18:44:38] <BBB> so you might want to look at our proposed project list [18:44:48] <BBB> because particular projects will have suggested qualification tasks [18:45:00] <BBB> see http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010 [18:47:19] <gangil> BBB: thanks , I googled it though :) [18:48:18] <BBB> good :) [18:48:30] <BBB> a codec I'd be willing to mentor is WVP2, but there's some others as well [18:48:54] <BBB> you can also suggest your own codec, but be aware that codecs are difficult, so you'll want a good mentor to help you in th einitial stages [18:49:24] <BBB> I'm not saying you're not competent, I just know how difficult it is ;) [18:52:07] <gangil> hmm... [19:08:06] <Vitor1001> BBB: sorry, but I don't think I'll be able to work on it very soon :( [19:23:05] <BBB> ok, I'll go at it then [19:23:37] <gangil> BBB: where can I get more info abt this project Implement a Windows Screen Video 2 decoder and can you elaborate onthe qualification task : reverse engineering the frame header ? [19:24:08] <BBB> merbanan would be a great mentor for that [19:24:13] <BBB> we used to have a wiki page [19:27:37] <BBB> hm, I cannot find the wiki page :( [19:27:43] <BBB> kshishkov: would you be willing to mentor? [19:27:46] <gangil> the video listed their looks very much the same as created by windows movie maker [19:27:47] <BBB> kshishkov: that way at least you get $500 [19:28:37] <kshishkov> BBB: unlikely, I'm going to spend that time trying to get out of here. I'll try to help though [19:32:02] <BBB> ok [19:32:21] <BBB> gangil: ok, I guess we'll have to wait for either merbanan, or I'll have to do it... vitor is too busy also, it seems :( [19:32:30] <BBB> gangil: can you email Benjamin Larson? [19:32:39] <BBB> google his name + ffmpeg to get his email addy [19:32:45] <BBB> ask him if he'd be willing to mentor [19:32:52] <BBB> if not I'll help you get set up [19:33:25] <gangil> ok [19:34:28] <BBB> sorry we don't have a mentor straight available [19:34:50] <kshishkov> it does not matter much though [19:35:00] <gangil> thanks :) [19:35:03] <BBB> in the mean time, I'd suggest that you get ida pro installed... google it, a company sells it, they have an old version (3.7 or so) available as a free download [19:35:37] <BBB> then using ida pro, open the MS .dll file that is used to decode wvp2 files, you can find that e.g. in the mplayer dll collection [19:35:50] <BBB> and mplayer will also serve as a good positive control to actually compare the output against [19:35:53] <kshishkov> it's wmvadvd.dll [19:35:56] <drv> http://www.hex-rays.com/idapro/idadownfreeware.htm [19:35:57] <BBB> that should get you a starting point [19:36:44] <BBB> ocne you've got it all set up and in front of you, you can start asking questions on where to start, it'll be a bit painful in the beginning but you'll get it quite quickly [19:36:49] <BBB> hopefully ;) [19:38:27] <gangil> Benjamin Larson tamom7rt(a)yahoo.ca [19:38:42] <drv> it's larsson [19:38:44] <gangil> this one seems to be it [19:38:58] <kshishkov> nope [19:38:58] <BBB> Larsson maybe [19:39:23] <kshishkov> and domain is .se [19:39:24] <BBB> banan @ ludd.ltu.se [19:40:17] <gangil> Benjamin LarssonÂ <banan(a)ludd.ltu.se > [19:40:22] <gangil> kk [19:40:25] <BBB> :) [19:40:49] <BBB> so what was your last year's project? [19:41:52] <gangil> it was regarding networking , mainly involving sockets SDL_net http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2009/tux4ki… [19:42:14] <gangil> and C [19:42:19] <gangil> ofcourse [19:55:49] <gangil> everyone suddenly got silent .. ?? or am I offline :S [19:56:10] <kshishkov> maybe you are [19:56:29] <kshishkov> or maybethere's nothing to discuss [19:58:48] <sancode> Hello. Who can check our software for LGPL-compliance and give any recommendations.. [19:59:15] <kshishkov> you can do it yourself, for example [20:02:12] <Dark_Shikari> sancode: you can ask [20:02:23] <Dark_Shikari> explain your situation and what you've done [20:02:53] <sancode> our program is FVD Suite. It uses LGPL FFmpeg. So no non-free libraries/codecs [20:03:04] <sancode> site is : http://flashvideodownloader.org/ [20:03:13] <sancode> it uses ffmpeg like extension for encoding video [20:03:17] <Dark_Shikari> say more useful things, like [20:03:23] <Dark_Shikari> "our product is proprietary" [20:03:27] <Dark_Shikari> or "our product is GPL" or [20:03:27] <Dark_Shikari> ... [20:03:33] <Dark_Shikari> and how you are distributing ffmpeg and so forth [20:03:46] <sancode> closed-sources. FFmpeg bundled with installer [20:03:54] <sancode> EULA has information about it [20:03:56] <Dark_Shikari> ffmpeg.exe, or ffmpeg libraries? [20:04:01] <sancode> ffmpeg.exe [20:04:10] <sancode> source code and build instructions also available [20:04:13] <Dark_Shikari> OK, first of all, in that case, there is no difference between LGPL and GPL ffmpeg (basically) [20:04:15] <sancode> http://flashvideodownloader.org/mirrors/ [20:04:19] <Dark_Shikari> so there is no reason why you can't include a GPL version [20:04:35] <Dark_Shikari> (and, given that x264 is GPL, and H.264 encoding is rather important for things like ipods, that might be a useful thing to do) [20:04:44] <BBB> lol :) [20:04:55] <Dark_Shikari> thus: [20:04:57] <BBB> sancode: did you check our license recommendations? [20:05:01] <Dark_Shikari> 1) Does your product include source code? [20:05:03] <sancode> build parameters [20:05:04] <sancode> FFmpeg version SVN-r21487, Copyright (c) 2000-2010 Fabrice Bellard, et al. [20:05:04] <sancode> built on Feb 4 2010 00:11:22 with gcc 3.4.5 (mingw-vista special r3) [20:05:04] <sancode> configuration: --extra-cflags=-fno-common --disable-shared --enable-static --d [20:05:04] <sancode> isable-doc --disable-ffplay --disable-ffserver --enable-memalign-hack --enable-b [20:05:04] <sancode> zlib --enable-libmp3lame --disable-network --enable-swscale --enable-avisynth [20:05:05] <Dark_Shikari> in the downloader [20:05:14] <BBB> http://ffmpeg.org/legal.html [20:05:15] <sancode> product not includes but includes link to source [20:05:20] <sancode> and all credits/COPYING [20:05:22] <Dark_Shikari> sancode: link to your website? [20:05:22] <sancode> with folder of ffmpeg [20:05:25] <Dark_Shikari> ok, that's good [20:05:28] <sancode> http://flashvideodownloader.org/ [20:05:34] <Dark_Shikari> Does the product include the (L)GPL? [20:05:37] <sancode> http://flashvideodownloader.org/fvd-suite/notes.php [20:05:45] <sancode> iyes [20:05:55] <Dark_Shikari> anyways, it looks like you're, from a superficial perspective, good [20:05:57] <Dark_Shikari> this is not legal advice [20:05:59] <Dark_Shikari> IANAL [20:07:20] <BBB> the links to ffmpeg.org, license info etc. on the download page are missing [20:07:33] <sancode> yes i know [20:07:50] <sancode> web-designer will be only after weekend [20:08:00] <BBB> well, that's one :) [20:08:00] <sancode> we will fix it [20:08:03] <BBB> ok [20:09:17] <sancode> besides ffmpeg [20:09:19] <sancode> we distribute [20:09:32] <sancode> CREDITS MAINTAINERS COPYING [20:09:38] <sancode> Build instructions (our Readme) [20:09:44] <sancode> where to download sources [20:09:46] <sancode> and instructions [20:10:14] <sancode> about dialog has information of ffmpeg too.. [20:10:20] <sancode> We plan to redisign it [20:10:44] <sancode> Now just: This products contains FFmpeg <link> [20:10:53] <sancode> next will be more informative [20:11:03] <gangil> /j #xelerance [20:11:17] <sancode> /j #xelerance [20:11:19] <sancode> sorry [20:11:41] <gangil> sorry [20:12:31] <sancode> EULA is http://dl.dropbox.com/u/1811883/license.txt [20:20:40] <BBB> the about dialog, eula and website should all say "this product contains ffmpeg <link> under the license <license + link>" [20:20:51] <BBB> and then some way for users to figure out where to get the sources you used [20:20:58] <sancode> ok [20:21:04] <BBB> doesn't have to be very wordy [20:21:07] <BBB> just as long as it's clear [20:21:34] <BBB> e.g. "this product contains <a href=..>ffmpeg</a> under the <a href=..>LGPLv2.1</a> (<a href=..>sources</a>) [20:21:34] <BBB> " [20:21:45] <BBB> that would be enough for the about dialog already [20:21:59] <BBB> as long as A) credits, B) license and C) sources used are all obvious [20:22:08] <sancode> good [20:22:50] <ohsix> is there an advertising clause? these are things that are nice to do but nobody is bound by that stuff [20:23:06] <sancode> i didn't understand [20:23:39] <BBB> ohsix: there is a credit clause, yes [20:23:52] <BBB> advertising is generally interpreted as "you cannot remove this message" [20:23:58] <BBB> which is lgpl/gpl-incompatible [20:24:03] <ohsix> where [20:24:35] <sancode> we are not using FFmpeg name for advertising [20:24:56] <BBB> 7b [20:25:09] <BBB> sancode: he doesn't mean advertising in that way ;) [20:25:23] <BBB> ohsix: let me quote [20:25:31] <BBB> ohsix: "Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work." [20:25:59] <BBB> ohsix: we interpret prominent as "it should be clearly visible, regardless of method of installation, use and acquisition, to people installing, using and downloading" [20:26:28] <BBB> ohsix: which means it should be in the program during running ("about dialog"), it should be visible during installatio ("in eula"), and it should be visible during download ("on website download page") [20:26:44] <BBB> ohsix: your lawyer might suggest something else, but if we're unhappy with your chosen solution, we'll sue your pants off :) [20:26:51] <ohsix> heh [20:27:20] <BBB> sancode: don't worry, I won't sue you, I'm just quoting a small part of the license, feel free to ignore ;) [20:27:57] <ohsix> thats if you use in part the library in an assemblage, and only for one of the possible licenses, as dark_shikari said as a binary and with what they're doing already its kind of moot to pick which one to adhere to [20:27:58] <sancode> okey [20:28:16] <BBB> ohsix: but clearly, nothing states that you HAVE to advertise ffmpeg in your about dialog, you could also do it in that startupscreen while the application loads, or in the help, or whatever [20:28:28] <BBB> ohsix: we just suggest doing it in the about dialog, since that's where you'd expect to find it [20:28:48] <ohsix> i get the suggestion part, and the niceties [20:29:38] <ohsix> but its basically an idle threat as its written and ever mentioned ;] [20:30:25] <sancode> main goal of application is download manager [20:30:41] <sancode> ffmpeg like extension, program will be work without ffmpeg [20:30:56] <sancode> next release we plan to do in installer page for selecting components [20:31:09] <sancode> user can replace ffmpeg.exe with own [20:31:13] <sancode> and it will be work too [20:33:26] <sancode> and we will and links to FFmpeg on downloading page [20:34:27] <BBB> sancode: sounds like you're doing well, license-wise [20:34:55] <ohsix> going above and beyond, even; but don't threaten him :\ [20:35:53] <CIA-92> ffmpeg: siretart * r22488 /branches/0.5/libswscale/swscale.c: [20:35:53] <CIA-92> ffmpeg: fix compilation issue on powerpc [20:35:53] <CIA-92> ffmpeg: unlike the ARCH_ macros, COMPILE_ALTIVEC needs to be tested more carefully [20:36:20] <sancode> ohsix, i did not understand your last sentense.. i am not native english speaker ( [20:36:47] <BBB> sancode: he says you're compliant and quite comfortably so [20:36:50] <ohsix> sancode: its nothing you need to worry about, you're doing fine [20:37:27] <sancode> ok) i understood now [20:39:40] <BBB> ohsix: nothing wrong with interpreting clauses of the lgpl in a way that is convenient to yourself [20:40:13] <ohsix> heh, its not even that, and thats being deceitful anyways [20:42:26] <sancode> so, recommendations: [20:42:26] <sancode> 1. add link to FFmpeg on main page/download page [20:42:26] <sancode> 2. More informative About [20:42:26] <sancode> 3. "this product contains ffmpeg <link> under the license <license + link>" [20:42:26] <sancode> 4. Links on main page: source codes/build instructions [20:42:48] <BBB> yes [20:43:10] <BBB> and add a link to ffmpeg.org in your EULA [20:43:16] <BBB> probably flvstreamer also [20:43:26] <sancode> okey [20:43:51] <sancode> thanks for your help! [20:47:45] <sancode> and one question.. [20:48:30] <sancode> references to the licenses should points to our site or gnu? [20:48:42] <justlooking_> sancode, you are aware your app http://flashvideodownloader.org/flash_video_downloader-1.9.8-fx.xpi says its not compatable with firefox 3.6 right ? [20:48:42] <sancode> or both? [20:48:55] <sancode> i don't know i am not developing it [20:49:29] <sancode> i am working only FVD Suite [20:49:34] <sancode> *with [20:53:21] <BBB> sancode: gnu is fine [20:53:41] <BBB> sancode: so http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html [20:54:31] <sancode> ok [21:01:25] <ohsix> Dark_Shikari: you there? [21:01:54] <ohsix> Dark_Shikari: param to decode_nal_units looks pretty suspect: http://paste.ubuntu.com/394242/ [21:02:35] <ohsix> wont be back for a bit to discuss it, but if you have any tips msg me; i'll be digging in a bit later, thanks! [21:16:51] <Yuvi> I seem to be asleep most of the time when diego is on irc [21:34:44] <gangil> merbanan: hi [21:37:14] <astrange> 12:00 <@Dark_Shikari> astrange has to keep updating his fork <- i'm working on ffmpeg frontend issues now so i can submit it with theora support soon [21:37:38] <astrange> in case anyone rewrite the vp3 decoder over again before then [21:38:04] <peloverde> really? you are going to submit it soon? [21:38:18] <astrange> not h264, but the framework part [21:38:30] <peloverde> still that's huge [21:54:59] <siretart`> Yuvi: I'm interested about the status of your ogg and theora work as well :-) [21:55:03] <astrange> i wanted to do pts "properly" in ffmpeg.c using reordered_opaque, but some demuxers (notably .h264) don't set it right in the first place [21:55:22] <astrange> so it looks like it's back to semi-hacked tracking decoder delay [21:56:13] <peloverde> siretart`: What's the status for 0.6? Are we still planning on branching tomorrow? [21:57:17] <siretart`> peloverde: that's what I'm currently trying to find out :-) [21:57:44] <siretart`> peloverde: do you feel we're ready yet? [21:58:21] <peloverde> siretart`: SBR is stable with no known issues. I'm waiting for google security review but don't have a time table on that [21:59:34] <astrange> i hope i haven't killed that icc thread by offering to diagnose that bug [21:59:41] <peloverde> I would like to see the regtest-mxf fixed on gcc-svn [22:00:05] <astrange> what arch/configure line? [22:00:31] <peloverde> http://fate.multimedia.cx/index.php?build_record=199882 [22:02:22] <astrange> ah, that one. let's see if i can reproduce it this time [22:03:00] <siretart`> peloverde: in any case, I'll try to discuss creating the branch with diego tomorrow. [22:03:19] <peloverde> siretart`: OK, sounds good [22:03:52] <siretart`> as much I'm really looking forward to -mt, AFAIUI its regression potential is pretty high, so releasing before merging it seems reasonable to me [22:05:48] <astrange> to avoid breaking vlc i'm going to turn it off and require the client to set thread_type appropriately, but i still agree [22:08:55] <peloverde> For 0.7 I want to see AAC in fate in some form [22:10:23] <Yuvi> siretart`: oh shit, that's tomorrow? [22:11:04] <Yuvi> well, the two biggest things I want to finish before 0.6 are 1. 4:2:2/4:4:4 and 2. fixing a bunch of smaller ogg seek bugs [22:12:02] <peloverde> Yuvi: What's the time table on that? [22:12:14] <Yuvi> I'll see if I can finish 4:2:2/4:4:4 today [22:12:45] <Yuvi> the seek stuff, I want to know what issues diego's having with it [22:13:00] <Yuvi> fixing the worst that I know about can probably be done in another day [22:13:14] <astrange> http://permalink.gmane.org/gmane.comp.video.ffmpeg.cvs/28612 this needs to be applied [22:13:20] <astrange> unless it magically compiles for someone else? [22:17:37] <astrange> 'configure --cc=/usr/local/gcc45/bin/gcc --enable-shared --extra-cflags=-m32 --extra-ldflags=-m32' passes make test [22:18:01] <astrange> on darwin, trying linux [22:19:47] <siretart`> Yuvi: is the work you're intending to do "contained"? Read: do you need to introduce new or remove existing files? Or do you expect they can be easily backported? [22:20:15] <siretart`> Yuvi: if not, waiting another week shouldn't really hurt either [22:21:14] <Yuvi> it's contained, but the seeking stuff won't be easily backported without porting it all [22:26:26] <siretart`> okay, then I'll try to talk to diego about the "seek stuff". [22:27:18] <siretart`> if its a non-issue, I think we could indeed branch tomorrow, and backport the 'remaining' ogg commits [22:42:57] <Yuvi> astrange: if mru doesn't respond, I say just apply it [22:55:53] <astrange> LDlibavformat/libavformat.so.52 [22:55:54] <astrange> /usr/bin/ld: internal error in override_version, at ../../gold/resolve.cc:61 [22:55:57] <astrange> collect2: ld returned 1 exit status [22:56:02] <astrange> better switch back to regular ld [23:12:16] <astrange> http://pastebin.com/QKCCmZU5 [23:25:42] <CIA-92> ffmpeg: aurel * r22489 /trunk/libavcodec/libxvidff.c: libxvid is producing standard mpeg4 so it don't need its own codec id [23:26:54] <astrange> if(avctx->rc_buffer_size && avctx->bit_rate*av_q2d(avctx->time_base) > avctx->rc_buffer_size) [23:27:03] <astrange> this is numerically suspicious [23:27:15] <astrange> avctx->bit_rate*av_q2d(avctx->time_base) should == avctx->rc_buffer_size [23:27:21] <astrange> so if it rounds wrong it fails [23:35:23] <CIA-92> ffmpeg: aurel * r22490 /trunk/libavformat/ (rmdec.c rm.h): export sipr_subpk_size for future use by matroska demuxer [23:36:48] <CIA-92> ffmpeg: aurel * r22491 /trunk/libavformat/ (rmdec.c rm.h): export rm_reorder_sipr_data() for future use by matroska demuxer [23:49:55] <CIA-92> ffmpeg: aurel * r22492 /trunk/libavformat/ (Makefile matroskadec.c matroska.c): matroskadec: add support for SIPR audio tracks

1 0

IRC log for 2010-03-11
by irc＠mansr.com 12 Mar '10

12 Mar '10

[00:39:56] <CIA-92> ffmpeg: mru * r22443 /trunk/configure: [00:39:56] <CIA-92> ffmpeg: configure: add --disable-everything option [00:39:56] <CIA-92> ffmpeg: This disables all codecs, formats, etc. It saves some typing when [00:39:56] <CIA-92> ffmpeg: only a few components are desired. [00:39:56] <CIA-92> ffmpeg: mru * r22444 /trunk/configure: configure: use map() function in a couple of places [00:43:01] <CIA-92> ffmpeg: mru * r22445 /trunk/configure: configure: remove stray semicolon [02:32:52] <CIA-92> ffmpeg: mru * r22446 /trunk/libavcodec/dsputil.c: [02:32:52] <CIA-92> ffmpeg: Add some required casts [02:32:52] <CIA-92> ffmpeg: These casts are correct and safe. The pointers are guaranteed to [02:32:52] <CIA-92> ffmpeg: have proper alignment, and aliasing is not a problem with character [02:32:52] <CIA-92> ffmpeg: types. [02:32:53] <CIA-92> ffmpeg: mru * r22447 /trunk/ffplay.c: ffplay: use correct format specifiers in printf() [02:32:54] <CIA-92> ffmpeg: mru * r22448 /trunk/libavcodec/snow.h: [02:32:54] <CIA-92> ffmpeg: snow: remove unused stub functions [02:32:55] <CIA-92> ffmpeg: w53_32_c() and w97_32_c() are defined as stubs when snow encoder is [02:32:55] <CIA-92> ffmpeg: disabled. In this case, those functions are not referenced at all [02:32:56] <CIA-92> ffmpeg: and do thus not need to be defined. [02:32:56] <CIA-92> ffmpeg: mru * r22449 /trunk/libavutil/sha.c: sha: add missing include [02:32:57] <CIA-92> ffmpeg: mru * r22450 /trunk/libavutil/random_seed.c: random_seed: try other alternatives if reading /dev/random fails [02:32:57] <CIA-92> ffmpeg: mru * r22451 /trunk/libavutil/random_seed.c: indent [02:35:53] <CIA-92> ffmpeg: michael * r22452 /trunk/ffplay.c: [02:35:53] <CIA-92> ffmpeg: Implement framedrop. [02:35:53] <CIA-92> ffmpeg: Replace SDL timer by a seperate thread, more accurate and less annoying. [02:35:53] <CIA-92> ffmpeg: frame drop is enabled by default, bug reports welcome. [02:35:53] <CIA-92> ffmpeg: Fixes issue1191 [03:47:49] <astrange> i was going to redo ffmpeg.c's a/v sync to use reordered_opaque but it requires changing more stuff than i'd hoped, hm [06:26:52] <KotH> moin [06:59:14] <elenril> anyone familiar with how put_bmp_header() works? [06:59:30] <elenril> i wonder why it pads the extradata to even size, but doesn't account for it in size [07:00:42] <kshishkov> because it's in the spec [07:00:49] <elenril> in what spec? [07:00:55] <kshishkov> otherwise it would be treated as part of extradata [07:01:24] <elenril> got a link? [07:01:39] <kshishkov> let's just say that all M$ spec include padding - in AVI chunks, in BMP spec as well [07:01:51] <kshishkov> bbl [07:02:02] <elenril> well wmp has problems with this [07:18:01] <Yuvi> there, the ogg demuxer now seeks to keyframes at least as well as mplayer [07:18:36] <CIA-92> ffmpeg: conrad * r22453 /trunk/ (3 files in 2 dirs): oggdec: Save offset of the page needed to reconstruct the current packet [07:18:36] <CIA-92> ffmpeg: conrad * r22454 /trunk/ (libavformat/oggdec.c tests/ref/seek/lavf.ogg.ref): [07:18:36] <CIA-92> ffmpeg: oggdec: Set data_offset to the right value [07:18:36] <CIA-92> ffmpeg: Otherwise it gets set automatically to a page midstream and prevents seeking [07:18:37] <CIA-92> ffmpeg: to the first page. [07:18:37] <CIA-92> ffmpeg: conrad * r22455 /trunk/libavformat/ (oggdec.c oggdec.h): [07:18:38] <CIA-92> ffmpeg: oggdec: Move ogg_find_stream and ogg_gptopts to oggdec.h [07:18:38] <CIA-92> ffmpeg: (skeleton will need them) [07:18:39] <CIA-92> ffmpeg: conrad * r22456 /trunk/libavformat/oggdec.h: oggdec: Check that we have a codec in gptopts (needed for skeleton) [07:18:39] <CIA-92> ffmpeg: conrad * r22457 /trunk/libavformat/ (oggdec.c Makefile oggparseskeleton.c oggdec.h): oggdec: Parse skeleton to determine the start time of each stream [07:18:40] <CIA-92> ffmpeg: conrad * r22458 /trunk/libavformat/oggdec.c: oggdec: Fix duration calculation for streams with non-zero start [07:18:40] <CIA-92> ffmpeg: conrad * r22459 /trunk/libavformat/ (oggparsespeex.c oggparsevorbis.c): oggdec: Don't use ogg_stream's seq for vorbis or speex headers [07:19:21] <CIA-92> ffmpeg: conrad * r22460 /trunk/libavformat/oggparsevorbis.c: oggdec: Fix memory leak in setting up vorbis headers [07:19:21] <CIA-92> ffmpeg: conrad * r22461 /trunk/libavformat/oggdec.c: oggdec: Move PTS/DTS calculation to a function [07:19:21] <CIA-92> ffmpeg: conrad * r22462 /trunk/ (libavformat/oggdec.c tests/ref/seek/lavf.ogg.ref): [07:19:21] <CIA-92> ffmpeg: oggdec: Determine pts and filepos on a packet basis in read_timestamp [07:19:21] <CIA-92> ffmpeg: This takes into account whether the granule defines the start or end times [07:19:22] <CIA-92> ffmpeg: of packets, and sets the correct file offset of the associated page. [07:19:22] <CIA-92> ffmpeg: conrad * r22463 /trunk/libavformat/ (oggdec.c oggdec.h): oggdec: Seek to keyframes [07:19:51] <Yuvi> now to finish the *really* ugly stuff to fix issue 592 and make it able to seek to individual packets [07:23:26] <astrange> i didn't notice until just now that the mkv encoder can't do skippable simpleblocks [07:23:35] <astrange> i guess that needs pkt_flag_skippable or something :/ [07:23:59] <Yuvi> yeah, I don't think the api is there for that unfortunately :( [07:43:15] <astrange> Dark_Shikari: can i have your fuzzer? i want to make sure there's no deadlocks in h264+mt [07:46:27] <Dark_Shikari> astrange: ok [07:47:03] <Dark_Shikari> piece 1: http://pastebin.org/109455 [07:47:22] <Dark_Shikari> piece 2: [07:47:23] <Dark_Shikari> gcc -Wall -O3 -lavutil fuzzer.c -o fuzzer;rm log.$x.txt;rm failures.$x.txt;for a in $(seq 100000 120000);do echo $a >> failures.$x.txt;nice -n19 ./fuzzer input.ogv test.$x.ogv $a;export a;nice -n19 bash -c 'ffmpeg -y -i test.ogv -f null /dev/null > log.$x.txt 2>&1' 2>> failures.$x.txt;done [07:47:35] <Dark_Shikari> where $x is some number (to allow many simultaneous scripts) [07:47:45] <Dark_Shikari> piece 3: while true;do v=$(top -n 1 -b | grep ffmpeg | cut -c47-48);echo $v;if [ $v -gt 50 ]; then echo "killing";kill -9 `top -n 1 -b | grep ffmpeg | grep -v "grep" | cut -c1-5`;fi;sleep 1;done [07:48:38] <Dark_Shikari> to autokill processes that use up all the memory (due to that bug/bad behavior in interleaved_write) [07:48:56] <Dark_Shikari> note this is preferable to ulimits because it tells you in the log that it was KILLED, not segfaulted, so it distinguishes it from a crash. [07:49:22] <Dark_Shikari> you can repurpose it for CPU time instead of memory usage trivially, which would allow you to catch deadlocks in an automated manner [07:49:54] <Dark_Shikari> (I would prefer to run both simultaneously, to avoid oom) [07:50:29] <Dark_Shikari> oom was a huge problem with fuzzing ogg [08:25:10] <CIA-92> ffmpeg: mstorsjo * r22464 /trunk/libavformat/rtsp.c: [08:25:10] <CIA-92> ffmpeg: RTSP muxer: Create the SDP with the numerical IP of the peer [08:25:10] <CIA-92> ffmpeg: instead of using the original host name [08:33:56] <CIA-92> ffmpeg: mstorsjo * r22465 /trunk/libavformat/rtsp.c: Cosmetics, break a long line, fix brace placement [10:18:19] <bilboed-tp> siretart`, I can't see those arguments here :) [10:18:51] <siretart`> bilboed-tp: sorry? you yelled your opinion on sticking with 0.5 very vocally in this channel [10:19:05] <bilboed-tp> yah... TWELVE MONTHS AGO [10:19:14] <siretart`> no, this week [10:19:39] <siretart`> but anyway, I think we agree on the problem, but (maybe) disagree on the way to go [10:20:53] <DonDiego> what's the beef now? [10:21:44] <pJok> mornings :) [10:42:05] <kshishkov> pJok: goda flera morgnar [10:51:08] <kshishkov> mate! [10:51:17] <pross-au> Gday [10:52:01] <kshishkov> I've looked at all binkw32.dll I can finds (i.e. 0.5a and 0.8a) and indeed, looks like there's no BIK[ac-e] [10:53:27] <CIA-92> ffmpeg: pross * r22466 /trunk/libavcodec/binkaudio.c: Make binkaudio work with ff_float_to_int16_interleave_c (martin at martin dot st) [10:57:53] <pross-au> you're going to have to dig deeper kshishkov [10:59:47] <kshishkov> no, simply put ESAMPLEWELCOME somewhere and forget about it [11:00:12] * kshishkov wants to RE that old WMV3 format [11:03:57] <DonDiego> kshishkov: yes, please RE that :) [11:04:49] <kshishkov> that would require either working VM or an act of necromancy [11:07:24] <pross-au> there's another WMV3 format? [11:07:46] <kshishkov> yes, older one [11:08:04] <pross-au> You're really scaping the bottom of the barrel kshishkov [11:08:36] <kshishkov> at least I have many barrels to scrap [11:08:43] <kshishkov> any suggestions on what to RE? [11:09:09] <pross-au> Pace yourself! [11:09:21] <kshishkov> hmm? [11:09:39] <pross-au> VP7 [11:09:53] <pross-au> But its even more pointless then Bink Audio [11:10:08] <kshishkov> what's not pointless then? [11:10:21] <pross-au> MS-MPEG4 [11:10:29] <kshishkov> we have that [11:10:30] <pross-au> (Past tense though) [11:10:52] <DonDiego> kshishkov: vp4 [11:10:58] <DonDiego> on2 audio [11:11:06] <DonDiego> oh, i have a good one: twinvq [11:11:35] <kshishkov> DonDiego: ask Vitor to remove current twinvq support first ;) [11:14:18] <kshishkov> I agree we should RE those VP codecs though [11:16:46] <DonDiego> urm [11:16:52] <DonDiego> that's not the one i mean.. [11:18:16] <pross-au> VP4 and VP7? [11:18:19] <DonDiego> voxware [11:18:27] <DonDiego> kshishkov: voxware, go for that one.. [11:18:41] <kshishkov> pross-au: both [11:18:56] <DonDiego> kshishkov: there's also a vp3 variation we do not support [11:18:57] <kshishkov> DonDiego: that's not fair, I was the one who asked for supporting it [11:19:00] <DonDiego> vp31 or so [11:19:10] <kshishkov> unlikely [11:19:12] <DonDiego> kshishkov: hmm? [11:19:19] <DonDiego> you asked for what? [11:19:31] <kshishkov> for voxware support [11:19:43] <DonDiego> from whom? [11:19:54] <DonDiego> i'm not following [11:20:09] <kshishkov> I expressed a wish for it to be supported [11:20:22] <DonDiego> where? [11:20:32] <kshishkov> here, on IRC [11:20:50] <pross-au> kshishkov: SO! You've convinced DonDiego to share that Wish too [11:21:13] <DonDiego> i've wanted voxware for a long time [11:21:35] <kshishkov> here pirates used it instead of MP3 for rips [11:21:46] <kshishkov> what's your reasoon? [11:22:37] <DonDiego> i have a cool old movie that uses it [11:22:39] <DonDiego> vamps [11:23:00] * kshishkov has some cool old movies using it too [11:23:45] <DonDiego> is it settled then? :) [11:23:58] <kshishkov> yes, let's go convince voroshil ;) [11:24:05] <DonDiego> http://www.imdb.com/title/tt0114826/ [11:25:32] <kshishkov> mine is better - http://www.imdb.com/title/tt0062759/ [11:26:40] <CIA-92> ffmpeg: michael * r22467 /trunk/ffplay.c: [11:26:40] <CIA-92> ffmpeg: Make rdft speed user configureable. [11:26:40] <CIA-92> ffmpeg: Change default speed back to a slower variant. [12:26:58] <elenril> kshishkov: can you point me to the specs you were talking about? [12:29:00] <kshishkov> elenril: you've not specified what format you're talking about either [12:29:55] <CIA-92> ffmpeg: pross * r22468 /trunk/libavformat/bink.c: Prevent memory leak introduced in r22389 in Bink demuxer: pass partial packets to decoder. [12:30:39] <elenril> i have problems with asf [12:31:31] <elenril> i think avienc uses ff_put_bmp_header() too [13:12:41] <elenril> http://i.iinfo.cz/urs-att/vim-112383453667211.gif [13:13:24] <kshishkov> but it's more likely to appear in Emacs first! [13:13:33] * twnqx hates ipod [13:43:58] <Honoome> kshishkov: actually, vim had already that… [13:45:31] <kshishkov> and what happens when you run "M-x clippy" in Emacs? [13:49:55] <Honoome> nothing, but I got M-x butterfly [13:50:24] <kshishkov> you are not on Ubuntu then [13:50:44] <Honoome> definitely not, who do you think I am? :P [13:50:58] <kshishkov> Diego Petten`o [13:51:14] <kshishkov> (aka not that Diego) [13:51:56] <Honoome> technically I'm Diego Elio now :P so that should stop the aliasing ;) [13:52:28] <kshishkov> not unless you change first name [13:54:00] <Honoome> kshishkov: I did [13:54:07] <Honoome> legally, my first name is “Diego Elio” [13:54:22] <kshishkov> that sounds like two names to me [13:54:47] <Honoome> there's no concept of second name in Italy anymore [13:55:17] <kshishkov> there's never been one here at all [13:57:09] <kshishkov> (no nobility with a train of first and last names either) [13:57:34] <Honoome> yeah that's different here [13:57:37] <Honoome> isn't it not, lu_zero? :P [13:58:01] <kshishkov> there's also Spain [13:59:42] <kshishkov> Honoome: if lu_zero==Luca B then I think I know his four first names [14:02:20] <Honoome> yeah it's him [14:02:46] <twnqx> any idea how to export metadata to a text file so i can edit it, and re-import it to a file? [14:03:05] <kshishkov> ffprobe infile > metadata.txt ? [14:03:29] <kshishkov> converting it into command line for FFmpeg is trivial too [14:04:38] <twnqx> 2> since ffprobe writes to stderr >_> [14:04:47] <kshishkov> whatever [14:04:53] <twnqx> but minor variations, indeed [14:05:18] * kshishkov lives by mathematician's principle "if solution exists, go to sleep again" [14:05:55] <twnqx> uh, is that major_brand, minor_version, compatible_brands metadata of the file? [14:06:23] <twnqx> and: is there a list of usable metadata fileds somewhere? [14:06:51] <twnqx> itunes has "is a part of a collection" and "album artist", which i'm looking for [14:08:13] <twnqx> hm no, ffprobe doesn't show them on the file [14:08:25] <kshishkov> ffmpeg -i infile [14:08:58] <twnqx> no difference [14:09:27] <kshishkov> then it's ignored in demuxer I think [14:09:39] <twnqx> mh [14:10:21] <twnqx> .mp4 is handled by the mov demuxer iirc? [14:10:38] <kshishkov> yeth [14:11:02] <av500> twnqx: major_brand, minor_version, compatible_brands metadata is some mp4/mov specific metadata [14:11:08] <twnqx> ok [14:14:11] <twnqx> the MOV_EXPORT_ALL_METADATA define is not reachable by a ./configure flag? [14:14:21] <kshishkov> no [14:15:13] * twnqx sees new metadata [14:15:23] <elenril> ask bcoudrier about that [14:15:42] * elenril would like to know why it exists too [14:17:20] <twnqx> elenril: how would i go about making the remaining metadata usefull? i see 0xa9,grp aART cpil covr [14:17:36] <twnqx> i suppose sovr will be... difficult [14:17:55] * elenril has no idea how mov works [14:18:01] <twnqx> it's mp4 :S [14:18:09] <elenril> same thing (almost) [14:18:12] <twnqx> well [14:18:14] <twnqx> question is more [14:18:21] <elenril> i tried to make sense of it a few times, but failed horribly [14:18:22] <twnqx> how do i add metadata types [14:18:35] <twnqx> the keys, e.g. [14:18:40] <twnqx> is there a list of them? [14:18:40] <elenril> add where? [14:18:47] <elenril> yes, in libavformat/avformat.h [14:19:37] <twnqx> so album_artist is defined. good. [14:23:23] <twnqx> i think i asked that before. ffmpeg can't place cover art in files, right? [14:23:40] <kshishkov> not yet [14:23:47] <kshishkov> but it will - by streamcopy [14:24:04] <kierank> god i hate windbg [14:24:40] <kshishkov> try DEBUG.EXE then ;) [14:24:49] <peloverde> What would be really sweet is to pull out the art, recode it and stick it back in [14:25:03] <twnqx> recode? [14:25:29] <elenril> i recall somebody saying he has a patch for extracting cover art as a stream [14:25:34] <kshishkov> peloverde: most of modern media has nothing to do with art [14:25:37] <elenril> Baptiste maybe [14:25:38] <peloverde> either reencode the png smaller (like pngout) or the jpeg like the lossless recopress in jpeg-progs [14:25:42] <elenril> kshishkov: s/modern// [14:26:27] <peloverde> Oh music isn't art but the album cover is one of the last bastions of art ;) [14:27:20] <kshishkov> elenril: yes, I've not heard good Czech composers either [14:28:10] * elenril mostly listens to videogame soundtracks =p [14:29:08] * kshishkov pulls out his colection of MIDI files ripped and converted out from Sierra games [14:29:46] <pJok> does ffmpeg actually support midi files? ;) [14:29:56] <kshishkov> not yet :( [14:30:10] <kshishkov> someone should add at least OPL2/3 synth [14:30:21] <twnqx> and .sid [14:30:32] <andoma> +1 for SID [14:30:43] <andoma> rockbox has a real tiny sidplayer in it [14:30:53] <kshishkov> andoma: adplug.sf.net ;) [14:30:58] <wbs> BBB: sorry for leaving in the middle of the flamewar yesterday - applied the luca-approved code with a big fat explanation [14:31:07] <BBB> haha, ok :) [14:31:13] <BBB> I didn't know that qualified as flamewar [14:31:29] <wbs> well, not really, but "active discussion" at least :-) [14:32:19] <wbs> the general problem is that in the rtsp muxer, we first announce an sdp, then after announcing we setup the individual streams - so either we create half-initialized rtp sessions and create the sdp from that, or then just create the sdp from the rtsp context instead [14:32:40] <BBB> yeah, I noticed, I guess this is OK [14:32:50] <wbs> yeah [14:32:53] <BBB> I'm not terribly happy with copying random data all over the place, but it works [14:33:09] <wbs> exactly; at least the big fat notice explains the two options and their implications [14:35:24] <wbs> as far as I see it, I'd regard the rtsp muxer competent enough to create its own sdp - it still relies on too much details that aren't explicitly mentioned in the avf_sdp_create interface, so the more detailed interface would be good in that sense, but if luca doesn't want that, this solution at least solves my problem for now [14:37:33] <BBB> Luca is right in a way, and don't forget he will always look at it from the PoV of the RTP muxing itself, without the RTSP [14:37:53] <wbs> yeah, from that perspective it's understandable [14:38:19] <wbs> but from the other perspective - there's nothing stopping me from crafting my own sdp and sending that in the announce, instead of the one provided by avf_sdp_create either [14:38:37] <wbs> if I'm unable to make avf_sdp_create output the thing I need [14:38:53] <BBB> of course [14:38:55] <wbs> except for code duplication, that is [14:38:58] <BBB> but we wouldn't want that in SVN ;) [14:38:59] <BBB> right [14:39:03] <wbs> exactly [14:39:08] <BBB> the copy is OK, we'll leave it as-is for now [14:39:14] <wbs> yeah [14:39:16] <BBB> maybe later we can convince him of a more dynamic interface for internal use [14:39:34] <wbs> yeah, someone runs into some other scenario requiring more customization [14:39:45] <wbs> add an if to that sentence to make it make sense ;P [14:41:49] <BBB> if any audio guru is online, how do you call this filter (top=before, bottom=after): http://people.gnome.org/~rbultje/filteraudio.png [14:42:23] <kshishkov> lowpass [14:43:55] <kshishkov> and inverting [14:44:03] <BBB> maybe that's my bug :) [14:44:14] <BBB> it doesn't invert [14:44:16] <BBB> just sometimes [14:44:26] <BBB> so this is lowpass? [14:44:30] * BBB wishes he had a control [14:44:32] <av500> kshishkov: lowpass, why? [14:44:33] <KotH> looks like a differentiation to me [14:44:56] <kshishkov> av500: less jiggly than before = lowpass :) [14:45:12] <av500> I would not say that is is less jiggly [14:45:35] <kshishkov> KotH: differentiation would make it even worse [14:46:50] <KotH> BBB: a differentiation could be also approximated by a high pass [14:47:02] <KotH> kshishkov: worse? depends on how you define good ;) [14:47:25] <kshishkov> KotH: a straight line [14:48:08] <peloverde> Its good to know that audacity is hideous on mac too and it's not just a linux thing [14:48:49] <KotH> BBB: i think, easierst is if you can get teh samples out and compare their frequency spectrum [14:49:36] <kshishkov> peloverde: at least it's less edgier on mac ;) [14:49:47] <kshishkov> even in Audacity itself [14:59:09] <BBB> the spetrum (in audacity) is almost the same [14:59:18] <BBB> I don't see a difference [14:59:35] <av500> the signals themselves do not look much different [14:59:40] <av500> xcept for the invert [14:59:41] <BBB> right [14:59:46] <BBB> so what is it? [14:59:50] <BBB> it's not lowpass [14:59:53] <kshishkov> placebo filter [14:59:59] <av500> fffilter? [15:00:01] <BBB> is it a peak sharpener? :) [15:00:06] <kshishkov> any real filter should affect spectrum [15:00:07] <BBB> devnullfilter [15:00:17] <BBB> kshishkov: did yuou load it in audacity? [15:00:22] <BBB> I can show you before/after spectrum [15:00:24] <BBB> they're the same [15:00:35] <peloverde> Where is the filter code? [15:01:27] <kshishkov> BBB: maybe try it with different window/length? [15:01:52] <peloverde> Is it the final filter created by the WMA post? [15:02:45] <BBB> http://people.gnome.org/~rbultje/spectrum.png [15:02:53] <BBB> peloverde: yes [15:03:06] <BBB> its effect is minimal [15:03:11] <BBB> I can see a minor change in the spectrum [15:03:14] <BBB> but not much [15:03:46] <BBB> top=before, bottom=after [15:04:35] <peloverde> take the fft coeffiecients of the filter (that's what you have right?) and export them [15:05:02] <BBB> the last filter does not do FFT [15:05:18] <peloverde> what does it do then? [15:05:26] <BBB> it's a simple direct form 2 filter [15:05:39] <peloverde> then give us the coefs [15:06:00] <peloverde> it should be easy to see what ti does based on those [15:07:04] <BBB> out[n] = in[n] * 0.93980580475 - in[n-1] * 1.8795833569 + in[n-2] * 0.93980580475 + out[n-1] * 1.9330735188 - out[n-2] * 0.93589198496 [15:07:20] <BBB> 1.8795... = 2*0.9398.... [15:07:31] <BBB> the out[n-1/2] coeffs make little sense to me [15:07:53] <kshishkov> looks like a lowpass IIR filter which just cannot shave hi frequencies because there aren't any [15:08:04] <BBB> hmm.... [15:08:10] <BBB> so I need a signal with more high freqs? [15:08:17] <BBB> maybe that earlier weird filter is also lowpass [15:08:22] * BBB disables [15:18:30] <BBB> http://people.gnome.org/~rbultje/spectrum2.png [15:18:40] <BBB> either I do something wrong, or it's a anti-lowpass filter [15:20:03] <BBB> wbs: are you sure your buffers are padded with FF_INPUT_BUFFER_PADDING_SIZE? [15:20:34] <wbs> BBB: that doesn't matter for that case [15:20:45] <BBB> oh ok [15:21:06] <wbs> if the last byte and the next one happen to be 0, we consume both and end up with size = -1 [15:21:20] <wbs> and then do a memcpy(, , -1) and get a spectacular crash [15:22:12] <BBB> right [15:22:17] <BBB> I guess patch = ok then [15:22:57] <wbs> ok, I'll wait a moment to see if luca or michael has anything to say about it. they reviewed it initially a year ago [15:24:10] <peloverde> kshishkov: did i do something wrong, this doesn't look lowpass to me: http://i.imgur.com/qSVVa.png [15:25:47] <av500> If I had to globally adjust all pts/dts, where would I keep the adjust value? in AVFormatContext? [15:27:51] <BBB> http://people.gnome.org/~rbultje/spectrum3.png [15:28:01] <BBB> another one with more intense high-frequency sounds [15:28:07] <BBB> again, no effect [15:31:19] * BBB hates the bad focus management on mac with spaces enabled [15:31:49] <KotH> BBB: have you checked the phase? [15:32:02] <KotH> BBB: could be that it's mostly a phase changing filter [15:32:54] * BBB looks at what phase is [15:33:23] <KotH> you know star trek? [15:33:32] <KotH> they have these nice and shiny weapons called phaser [15:33:41] <KotH> what comes out of them is a "phase" ;-) [15:34:09] <BBB> uhm [15:34:09] <BBB> ok [15:34:13] <BBB> but how do I analyze phase? [15:34:33] <av500> BBB: you study EE for a few years [15:37:00] <BBB> ;( [15:38:16] <BBB> http://people.gnome.org/~rbultje/spectrum4.png [15:38:26] <BBB> here it looks like an actual lowpass (check the 16kHz on the left) [15:38:43] <BBB> but that's a very minor effect, wouldn't you expect it to be stronger? [15:38:55] <BBB> kshishkov: is that what I'm looking for? [15:39:20] <peloverde> spectrum 4 looks like my filter [15:39:40] <BBB> ? [15:39:57] <peloverde> http://i.imgur.com/qSVVa.png [15:40:29] <av500> peloverde: ah, finally matlab :) [15:40:33] <peloverde> BBB do you have access to MATLAB? [15:40:41] <BBB> no [15:40:53] <peloverde> The uni doesn't have a site license? [15:41:03] <BBB> I study biology, dude :) [15:41:24] <peloverde> I know a lot of systems biology people that live in MATLAB :) [15:41:29] <BBB> hmm... [15:41:31] <BBB> I don't think we have it [15:41:34] <BBB> could check though [15:41:40] <BBB> but so can I conclude it's a lowpass then? [15:41:48] <BBB> I just wanted to convince myself and know what it means [15:42:27] <av500> no, it is a highpass [15:42:29] <peloverde> spectrum4 certainly doesn't look lowpass to me [15:42:38] <av500> it filters out very low frequncies [15:42:38] <peloverde> It looks like it's a DC removal filter [15:42:42] <av500> yep [15:42:47] <peloverde> highpass with a very low cutoff [15:43:16] <BBB> no, on the left is 16kHz [15:43:25] <BBB> according to the x-axis [15:43:27] <av500> 16hz [15:43:37] <BBB> oh! [15:43:39] <BBB> hmm... [15:43:41] <BBB> oi [15:43:43] <BBB> oops [15:43:48] <av500> you learn to read in biology? [15:43:55] <BBB> no wonder I didn't see it elsewhere, the big graphs started at 500Hz or so [15:43:58] <BBB> so it's a highpass? [15:44:09] <av500> yes, a DC remover as peloverde said [15:48:04] <janneg> av500: how is the Big Buck Bunny render machine doing? first 3 scenes are mostly done http://www.jannau.net/bbb_videowall/ [15:48:28] <av500> janneg: the BBB render machine turned out to by a crapacer with only 3 mem slots [15:48:35] <av500> so its 4GB for this pos [15:48:50] <av500> coz 2x4GB ram is ummm expensive [15:49:07] <av500> err, only 2 mem slots [15:49:09] <kshishkov> av500: buy 1x16GB ram then ;) [15:49:17] <av500> kshishkov: sell it to me [15:49:46] <kshishkov> av500: it'll get lost during sending [15:50:06] <av500> so will my payment, thanks for doing business with you :) [15:51:17] <janneg> av500: could be still useful. there are frames which render fine with less than 4G [15:51:49] <kshishkov> av500: if you send it via post then yes, if via bank then they'll refuse transerring it. It's always a pleasure to do business with Ukraine! [15:55:02] * kshishkov wonders why some av5.. guy cannot write a patch for Blender making it consume less RAM [15:55:43] <peloverde> just be glad you aren't stuck in this position: http://blogs.msdn.com/expressionencoder/archive/2010/03/10/9976633.aspx [15:57:14] <peloverde> BBB: if you don't have access to MATLAB, pylab and octave both have "ok" signal processing/analysis tools [15:57:38] <peloverde> I've always found the spectrum tool in audacity to be lacking [15:59:41] <BBB> av500: "DC remover", what is "DC" here? [16:00:15] <kshishkov> BBB: roughly speaking, zeroth frequency [16:00:21] <BBB> (I need to know abbreviations :) ) [16:00:24] <BBB> ah, ok [16:00:29] <av500> direct current [16:00:35] <kshishkov> constant component of the signal [16:00:36] <av500> vs AC = alternating current [16:00:49] <peloverde> "direct current" from when all this stuff was done with analog electronics [16:00:55] <BBB> ok [16:02:03] <kshishkov> BBB: look at me, I've never studied signal theory yet I somehow manage [16:19:49] <KotH> BBB: dc remover == highpas with a very low filter frequency [16:20:10] <mru> a capacitor [16:20:44] <mru> everything is simpler in analogue [16:21:02] <KotH> a capacitor is a phase shifter ;)$ [16:21:12] <mru> that too [16:21:36] <KotH> and analog is a lot more difficult to get right than digital [16:21:47] <KotH> but, i have to go now... [16:21:51] * kshishkov remembers calculating LC-circuit properties with complex numbers [16:21:56] <KotH> have fun decyphering strange signals [16:22:13] <kshishkov> KotH: but we communicate with them [16:22:18] <KotH> kshishkov: yeah.. i did that too.. in highschool... and got weird looks from all my classmates ;) [16:22:22] <kshishkov> we == mere eartlings [16:23:18] <kshishkov> I probably was the only one who was not freaked by complex numbers [16:24:10] <KotH> .o0(that explains a lot about kshishkov) [16:24:32] <mru> in uni our first exam in circuit theory was a bit of a fiasco [16:24:39] <mru> 6 of 250 passed [16:24:51] <mru> yes, I was one of them [16:24:56] <kshishkov> we had intermediate test with similar results [16:25:31] <kshishkov> and "6 of 250" was an outcome of the first test in math! [16:27:04] <CIA-92> ffmpeg: mstorsjo * r22469 /trunk/libavformat/rtpenc_h263.c: [16:27:04] <CIA-92> ffmpeg: Fix a crash in the H.263 RTP packetizer [16:27:04] <CIA-92> ffmpeg: If size == 1 and buf[0] == 0 and buf[1] == 0 (the first byte after the [16:27:04] <CIA-92> ffmpeg: buffer), it would set size = -1 and crash in the later memcpy. [16:27:27] <kshishkov> it's pretty remarcable how our high schools manage to produce thousands of students knowing perfectly nothing [16:27:48] <mru> sounds just like sweden [16:28:04] <wbs> sounds mostly like finland, too ;P [16:28:28] <mru> finland is a part of sweden, no? [16:28:33] <kshishkov> s/Finland/Österland/ [16:28:59] <mru> just kidding [16:29:07] <mru> everybody knows it's part of russia [16:29:19] <mru> /o\ [16:29:22] <wbs> ;P [16:29:26] <kshishkov> mru: guess what, I did not even get high marks for English at school [16:29:49] <mru> I didn't attend english class in school [16:30:55] <andoma> but you're half native [16:31:26] <mru> many a brit would dispute that assertion [16:31:41] <thresh> i got "A", but my english still sucks [16:32:00] <mru> thresh: it's better than your french [16:32:16] <mru> I thought _my_ french sucked... [16:32:26] <kshishkov> mru: try mine ;) [16:32:49] <thresh> mru: ha-ha, true [16:32:53] <kshishkov> I'm not good at English but I don't know French at all [16:33:03] <av500> ffrench! [16:33:13] <thresh> well, actually mru teached me a bit of french [16:33:21] <mru> that's a scary thought [16:33:25] <kshishkov> av500: been there, moved to VVmpeg [16:33:27] <thresh> like 'just drop last three or four letters and it'll be ok' [16:33:27] <mru> because nobody ever taught me any [16:33:44] <av500> of, so ffcon in paris it is! [16:34:02] <kshishkov> thresh: and read a group of three vowels as one [16:34:31] <mru> av500: and here I was thinking it would be nice to have it in Nice [16:34:41] <thresh> kshishkov: so you do know french better than me! [16:35:05] <kshishkov> thresh: haven't you studied "War and Peace" at school? [16:35:10] <mru> any group of three or more vowels is pronouced like swedish å or ö [16:35:28] <kshishkov> "river" or "island"? [16:35:36] <kshishkov> SCNR [16:35:49] <thresh> kshishkov: they didnt force us to read french phrases [16:36:07] <kshishkov> thresh: well, what's left in that book then? [16:36:21] <thresh> kshishkov: 'Austerlitz sky' is all i remember [16:37:13] <kshishkov> thresh: then you remember much more than me. All I remember is that is was horiible long bunch of words next to impossible to read. [16:37:34] <av500> mru: we can ask ti to sponsor it :) [16:37:41] <av500> they have a nice place in nice [16:38:16] <thresh> kshishkov: I enjoyed it. Probably because I read it on summer vacs being ~2k km away from my computer and that was the only source of entertainment there. [16:39:14] <thresh> except for keeping the campfire and shooting the cans. [16:39:15] <kshishkov> thresh: in such circumstances people even enjoyed Nietzsche [16:40:27] <mru> nietzsche is good reading when near an abyss [16:41:29] <kshishkov> does its bottom count as "near"? [16:41:44] <mru> are there monsters there? [16:41:57] * kshishkov looks around [16:41:59] <kshishkov> not now [16:43:27] <mru> I suspect his idea of a monster may have included trolls [16:44:47] <kshishkov> told you once, I fit a definition of troll - "a creature supposed to live in Scandinavia but which doesn't" [16:45:09] <kshishkov> also living under the bridge connecting Europe and Asia doesn't help either [16:47:10] * pJok sends kshishkov off to stockholm [16:47:43] <kshishkov> I don't think that prank will work second time [16:47:58] <pJok> true [16:49:57] <kshishkov> pJok: actually it was Ben who tried it in 2009 [17:08:44] <BBB> time now to understand that frequency domain filter I guess [17:09:35] <kshishkov> that's just time-domain filter in different domain :P [17:09:58] <mru> frequency-domain filtering is conceptually simple [17:10:17] <mru> 1. take your time-domain signal [17:10:24] <mru> 2. apply transform to frequency domain [17:10:37] <mru> 3. modify components to your heart's desire [17:10:42] <mru> 4. transform back to time domain [17:11:03] <av500> 5. profit? [17:11:23] <mru> for example, to implement a low-pass filter, you simply set all coefficients above the cutoff to zero [17:12:37] <mru> in practice it won't be that perfect of course [17:12:58] <kshishkov> depends on transform [17:13:04] <mru> to get a perfect filter you'd need to do the transform on an infinitely long sequence [17:13:11] <av500> overlap/add [17:13:23] <mru> when you slice it up, you get a bit of leakage around the edges [17:13:29] <kshishkov> windowing to hide artifacts, whatever [17:23:31] * pJok hides kshishkov in the artifacts [17:23:51] <kshishkov> pJok: I'm too big to be hidden [17:25:13] <pJok> tells something about the artifacts then... [17:25:35] <iive> kshishkov: you are too poor to be big. ;) [17:26:14] <BBB> uhmm.... [17:26:24] <BBB> mru: I love you too, now can you translate all that to english for me? [17:26:31] <BBB> I understand things like plus and minus [17:26:42] <BBB> I don't even understand how FFT does what it does [17:26:45] <kshishkov> iive: ask some people who've actually seen me like mru/merbzt/andoma/superdump [17:26:58] <kshishkov> BBB: ask me [17:27:04] <BBB> ask [17:27:16] <iive> :O [17:27:26] <mru> BBB: I recommend you get a book on signal theory and read it [17:27:28] <kshishkov> FFT takes your ordinary signal and transforms it to sine waves [17:27:52] <kshishkov> real part = sine wave amplitude, imaginary part - phase (i.e. shift) [17:28:10] <kshishkov> it does it by magic ;) [17:28:11] <astrange> i'm not getting any roundup emails except for when i add a new bug... [17:28:16] <mru> the basic premise is that any signal can be represented as a sum of sines of various frequences and phases [17:28:31] <kshishkov> astrange: not nosy enough then [17:29:11] <mru> if the signal is symmetrical around t=0 you get all cosines [17:29:16] <mru> i.e. same phase [17:29:31] <mru> and nice, real-valued output [17:30:02] <kshishkov> BBB: cycle FFplay output modes for audio file to understand that idea better ;) [17:32:09] <BBB> so im = phase [17:32:13] <BBB> re = ampl [17:32:16] <BBB> hmm... [17:32:18] <BBB> interesting [17:32:19] <kshishkov> also isn't it said one has to understand Maxwell's equations before even touching electronics? [17:32:37] <mru> BBB: polar can coordinates help here [17:32:57] <kshishkov> and Euler's formula! [17:33:27] <mru> and e^(pi*j) = -1 [17:33:30] <mru> never forget that [17:33:57] <kshishkov> mru: I prefer e^(i*pi) + 1 = 0, it has _all_ important constants that way [17:34:19] <mru> depends on which ones you consider important [17:34:21] * kshishkov wonders why here people use "i" for imaginary one [17:34:26] <mru> it doesn't have G or alpha [17:34:31] <kshishkov> mru: one and zero of course [17:34:51] <kshishkov> two transcendental numbers is a bonus too [17:34:57] <mru> yep [17:35:13] <mru> but zero is always implicitly present [17:35:27] <mru> without zero, everything else is meaningless [17:39:50] * kshishkov also remembers how to integrate and differentiate f(x)=e^x [17:40:15] <mru> impressive! [17:43:48] <CIA-92> ffmpeg: rbultje * r22470 /trunk/libavcodec/ (acelp_vectors.c amrnbdec.c sipr.c acelp_vectors.h): Fix spelling. [18:56:09] <Dark_Shikari> mru: just ask the lambda calculus [18:56:30] <kshishkov> what's so special about that either? [18:57:21] <Dark_Shikari> all numbers are defined as successors of zero ;) [18:57:47] <kshishkov> natural ones only [18:59:57] * elenril never understood what lambda calculus is [19:00:15] <kshishkov> elenril: look at APL [19:00:18] <kshishkov> or Lisp [19:00:34] <kshishkov> or Perl without explicit variable names [19:00:48] <elenril> :effort: [19:01:31] <Dark_Shikari> elenril: go to school [19:01:47] * elenril doesn't have time for that [19:01:54] <Dark_Shikari> sure you do [19:01:58] <Dark_Shikari> you haven't submitted patches to x264 [19:01:59] <elenril> i have to procrastinate [19:02:00] <Dark_Shikari> which means you surely have time [19:02:17] <elenril> (and write my bc paper) [19:02:56] <kshishkov> on what? [19:03:13] <elenril> black holes [19:03:42] <mru> don't go too close [19:03:50] <mru> stay this side of the horizon [19:03:52] <elenril> visualisation of what infalling observer sees [19:04:16] <kshishkov> hasn't that Schwarzschieldt guy written all about them? [19:04:16] <mru> he'll be ripped to pieces before he has a chance [19:04:17] <elenril> meh, it's no fun here [19:04:22] <Dark_Shikari> mru: not with a big enough one [19:04:41] <elenril> you could cross the horizon without even knowing it [19:04:52] <Dark_Shikari> elenril: you may have been born inside the horizon [19:04:56] <elenril> actually you always see the horizon ahead of you [19:04:57] <Dark_Shikari> if the universe is closed, it is a black hole [19:05:31] <kshishkov> or fridmon [19:05:52] <mru> Dark_Shikari: in that case, prepare for the big crunch [19:06:16] <Dark_Shikari> mmmm. crunch. [19:08:34] <kshishkov> elenril, wasn't the process of falling supposed to take infinite time anyway? [19:09:21] <mru> kshishkov: in the reference frame of the faller, yes iirc [19:09:26] <mru> bloody relativity [19:09:47] <elenril> mru: no, the other way around [19:09:59] <kshishkov> mru: and outside it's unobservable because of event horizon. Fun! [19:10:01] <elenril> it's infinite time for the rest of the universe [19:10:03] <Dark_Shikari> it takes infinite _external_ time in the reference frame of the faller [19:10:14] <Dark_Shikari> thus, when you cross the event horizon, infinite time will have passed for an _observer_ [19:10:19] <Dark_Shikari> because time dilation is infinite at the event horizon [19:10:23] <Dark_Shikari> which of course means you will never hit the singularity [19:10:29] <elenril> actually one of the basic postulates in GR is that timespace is locally flat [19:10:53] <mru> ~summon Xeno [19:11:04] <Dark_Shikari> s/o/u [19:11:21] <kshishkov> elenril: I think you should go to #x264-dev and embarass DS there by proposing better SIMD than he wrote for x264 [19:11:38] <kshishkov> Dark_Shikari: it's avoiding trademark [19:11:52] <Dark_Shikari> kshishkov: patches welcome [19:13:41] * elenril would have to learn asm first [19:13:49] <Dark_Shikari> that takes a few hours [19:14:22] <elenril> and it's not applicable to metadata anyway =p [19:16:03] <kierank> write some metadata SEIs [19:16:40] * iive suspects somebody is confusing event horizon with light speed travel [19:18:04] * elenril suspects it's iive [19:18:51] * elenril reads what Dark_Shikari wrote again [19:18:53] <elenril> wait, what? [19:19:05] <elenril> no, you will hit singularity in a finite time [19:19:20] <Dark_Shikari> elenril: in your reference frame [19:19:25] <elenril> yes [19:19:27] <Dark_Shikari> in an observer's frame, infinite time [19:19:40] <Dark_Shikari> in the SINGULARITY'S FRAME, infinite time [19:19:49] <Dark_Shikari> thus, the singularity won't exist when you hit it. [19:20:11] <Dark_Shikari> hawking radiation etc [19:21:22] <_av500_> infinite time in pts or dts? [19:21:30] <Dark_Shikari> hahahaha. [19:24:19] <iive> Dark_Shikari: the time delay is caused by the gravitation. so the event horizon is not factor in it. also, light always travel at constant speed, so you will see the object until it "hides". [19:25:00] <iive> now, i wonder if there is something interesting if you travel toward black hole with the speed of light.... [19:25:10] <Dark_Shikari> iive: gravitational time dilation [19:25:19] <Dark_Shikari> separate issue [19:26:20] <elenril> Dark_Shikari: singularity's frame? [19:26:51] <Dark_Shikari> er, better said, the frame in which the age of the black hole is measured [19:27:13] <elenril> that would be external observer's frame [19:27:16] <Dark_Shikari> yeah, I guess [19:27:19] <Dark_Shikari> or actually the horizon's frame [19:27:24] <Dark_Shikari> because hawking radiation is produced there [19:27:50] <elenril> you can't have a static frame on the horizon [19:29:03] <elenril> i.e if you're on the horizon, you _have_ to be moving, either in or out [19:38:02] <elenril> anyway, you have a point with hawking radiation, but it isn't very well understood so i wouldn't be so sure [20:13:41] <elenril> does anybody know why does ff_put_bmp_header() pad it to even size? [20:14:07] <elenril> but doesn't account for it when writing length [20:14:37] <elenril> it breaks wmv3 playback in wmp [20:14:55] <mru> elenril: it's the spec [20:15:04] <elenril> link? [20:15:11] <mru> microsoft.com ? [20:15:27] <elenril> http://msdn.microsoft.com/en-us/library/aa930622.aspx << this? [20:17:09] <mru> that defines the structure itself [20:17:19] <Vitor1001> elenril: Just a curiosity, you said you were a physicist... Undergrad? [20:17:40] <elenril> yes [20:17:56] <Vitor1001> Fun :) [20:18:13] <Vitor1001> Was there ~ 6 years ago... [20:20:00] <Vitor1001> elenril: In the US? [20:20:51] <elenril> no, cz [20:23:55] <mru> elenril: you may have found a bug [20:24:01] <mru> the padding is part of the RIFF spec [20:24:10] <mru> I don't see any mention of it in asf spec [20:25:49] <elenril> https://roundup.ffmpeg.org/issue1512 [21:03:13] <BBB> Koth: what's your email addy? [21:04:36] <janneg> BBB: attila at kinali dot ch [21:05:50] <KotH> BBB: just use firstname @ lastname dot country :) [21:05:53] <KotH> BBB: or google for my name [21:06:00] <KotH> BBB: or do as janneg said ;) [21:06:03] <BBB> :) thanks [21:08:43] <KotH> janneg: is it me or are there a lot of render errors in bbb? [21:09:07] <KotH> BBB: btw: i'm on -legal :) [21:09:17] <KotH> BBB: just not reading it very often ;) [21:11:49] <BBB> oh [21:11:52] <BBB> oops [21:11:55] <BBB> ok [21:11:58] <BBB> so opinion? [21:12:06] <BBB> I just CC anyone whose attention I need [21:12:41] <janneg> KotH: I blame blender foundation for publishing buggy sources [21:14:09] * KotH blames blender foundation [21:14:27] <KotH> BBB: cc'ing me is not a bad idea if i need to see something [21:14:38] <KotH> BBB: either cc me or tell me on irc that i should have a look [21:14:42] <BBB> ok, so now on to the content ;) [21:16:46] * BBB patiently waits for koth to say CMS on mphq is OK [21:19:45] * KotH is writing an email on that [21:30:54] <KotH> BBB: biff [21:33:18] <BBB> replied already [21:33:25] <BBB> thanks :) [21:49:56] <BBB> fun, a new flamewar [21:50:59] <KotH> flamewar? i'm just stating my opinions :) [21:53:54] <BBB> :) [21:53:56] <BBB> it's a joke [21:55:39] <BBB> anywya, joomla ok? [21:57:24] <KotH> havent had a look at it :) [21:57:45] <KotH> if it fullfills the three points, it's ok :) [21:58:27] <BBB> I'd say popular means = ok [21:58:32] <BBB> if drupal is ok also... [21:59:36] <KotH> whatever floats your boat :) [21:59:50] <KotH> it's you who will have to maintain the website [21:59:58] <KotH> you have to be able to live with the cms [22:00:04] <KotH> i only care about the admin side :) [22:00:25] <KotH> anyways.. i'm off to bed [22:00:27] <KotH> good night boys [22:00:56] <janneg> good night KotH [22:09:25] <BBB> lu_zero: so do I get the impression you want to help on the website? ;-) [22:58:38] <MrNaz> BBB you here? [22:58:46] <BBB> yes [22:58:50] <BBB> what did I break this time? [22:59:27] <MrNaz> nothing heh... there's still a problem with ffserver and im looking for someone to give a bounty to to fix it [22:59:41] <BBB> so I did break something [22:59:53] <BBB> but if you tell me what's broken, I can fix it [23:00:12] <MrNaz> also, i still owe ffmpeg for the last thing you fixed... ben told me he'd get back to me with ffmpeg's bank details so i can send some money [23:00:31] <BBB> oh, that'd be great [23:00:44] <BBB> I can send you the foundation bank details, what's your email? [23:01:02] <MrNaz> its audio... it broke quite a while ago, i can't pinpoint the build as it broke during the period ffserver was totally broken... video is working fine now though [23:01:50] <MrNaz> the problem is that when streaming, audio output is totally broken, it just outputs a screaming sound instead of audio [23:01:55] <BBB> ow. hmm... [23:02:06] <BBB> so it worked before I broke the http streaming? [23:02:07] <MrNaz> i'll get to the centre in a couple of hours and i can give you a demo [23:02:19] <MrNaz> no it broke around jan i think [23:02:25] <BBB> ok [23:02:31] <BBB> I can look into that [23:02:39] <BBB> can I reproduce in the same way as previously? [23:02:56] <BBB> also, have you tested that it's not specific to a particular codec? [23:03:09] <MrNaz> i've tried aac and mp3 [23:03:41] <MrNaz> however i have only tested with flv, not anything else [23:04:15] <BBB> that's fine [23:04:45] <BBB> I'll make a note and see if I can reproduce this tonight [23:04:52] <BBB> I'll probably go home in a bit [23:24:29] <kierank> hmmm where'd merzbt go...

1 0