Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

April 2010

1 participants
30 discussions

IRC log for 2010-04-29
by irc＠mansr.com 30 Apr '10

30 Apr '10

[06:37:43] <Tjoppen> oh dear. been away for a week - 400 new mail [06:47:19] <KotH> a wonderfully, sunny good morning to everyone [06:54:05] <superdump> morning [06:54:22] <elenril> sun is evil [06:59:47] * KotH puts some garlic on elenril [07:11:39] <av500> en gute morsche [07:12:34] <kshishkov> god morgon [07:13:24] * elenril wonders why does kshishkov have ukrainian ip [07:14:02] * kshishkov does not wonder why his box which he runs irssi from and situated in Ukraine has Ukrainian IP [07:14:38] <elenril> you left your box to commies? [07:16:03] <kshishkov> true Ukrainians think that the only place for commies is hanging in the noose [07:16:14] <kshishkov> but in principle yes [07:16:57] <kshishkov> it serves as a router there [07:20:33] <KotH> einen wunderschönnen, herrlich sonnigen guten morgen kshishkov! [07:20:46] <kshishkov> javisst! [07:21:04] <pJok> god morgon kshishkov :) [07:21:05] <kshishkov> I've heard that it's always good weather in this place [07:21:05] <KotH> ja..was? [07:21:12] <KotH> lol [07:21:21] <kshishkov> KotH: that's Swedish for "of course" [07:21:29] <kshishkov> goda morgnar, pJok [07:22:01] * KotH takes notes [07:25:38] <kshishkov> yep, FFmpeg is mostly Swedish so everybody else should be converted [07:26:44] <pJok> FFswedish [07:26:54] <kshishkov> precis [07:27:20] <merbzt> we can run that as a 1 april joke next year [07:28:13] <kshishkov> please register ffmpeg.nu and ffmpeg.se [07:36:45] <Tjoppen> lysande idé [08:03:01] <Kris_eva> Hi, I was wondering if we can copy video frame user data some how that is the CC data stored in a video frame [08:03:34] <kshishkov> and I wonder how this relates to developing FFmpeg [08:05:55] <Kris_eva> Sorry, I was hoping some one would be able to give me some idea here [08:06:15] <kshishkov> why not ask at #ffmpeg first? [08:07:12] <Kris_eva> in fact I did that but but no information [08:07:15] * KotH would wonder what would happen if a project would adopt an other language than english as official project language [08:07:22] <KotH> s/would wonder/wonders/ [08:07:35] <KotH> somehow my english is really bad these days [08:07:38] <kshishkov> KotH: det ska passa bra [08:07:40] * KotH blames spaam [08:07:49] <astrange> it works for many on sourcefore.jp [08:08:06] <hyc> hmm. libavutil already provides sha256 and rc4 [08:08:28] <hyc> we could drop the need of openssl/gnutls for librtmp if we also add hmac wrapper for sha256 [08:08:34] <hyc> and add dh key exchange [08:08:48] <KotH> hmac should be easy to do [08:08:53] <hyc> yes [08:08:58] <kshishkov> even I did that :) [08:08:58] <KotH> dunno about dh key-ex [08:09:16] <hyc> here's a compact one. ;) http://www.cypherspace.org/adam/rsa/dh-in-C.html [08:09:16] <spaam> KotH: dont blame me. blame MÃ¥ns this time ;) [08:09:24] <astrange> is aes.c more or less resistant to timing attack than openssl? [08:09:47] <spaam> kshishkov: Snacka mer svenska med KotH ;) [08:09:48] <kshishkov> benchmark it! [08:09:50] <hyc> that would allow support for rtmpe, but would still be missing support for rtmps [08:09:51] <pentanol> hi mru and other... perhaps soneone have clue why ffmpeg glitched on my arm while computing AVOptions? I've tried different combination, but it goes to segfault anyway after return from these function...av_opt_set_defaults2() [08:09:59] <hyc> but I suspect few people use rtmps [08:10:00] <KotH> spaam: nope, mru is correcting my bad english all the time, so he actually counters your attempts to undermine my authority [08:10:22] <kshishkov> spaam: fint [08:10:38] <KotH> spaam: i schnure mit der innere sproch wo i chan, nöd i einere won i kum verstohn [08:11:05] <spaam> KotH: snacka svenska istÃ€llet fÃ¶r tyska ;) borde lÃ€ra dig av kshishkov ;) [08:11:22] * kshishkov pretty sure that KotH should be prosecuting in Germany for violence to German language [08:11:28] <KotH> spaam: <elenril>this is *effort*</elenril> [08:11:33] <kshishkov> s/prosecuting/prosecuted/ [08:11:58] <KotH> kshishkov: my high german is better than that of most germans ;) [08:12:22] <kshishkov> s/better/higher/ because you're in Switzerland [08:12:38] <KotH> lol [08:12:45] <spaam> ;) [08:12:46] <KotH> .ch isnt that high [08:12:56] * KotH is at about 400müM [08:14:11] * elenril shoots KotH for highlighting him in vain [08:14:24] <elenril> also you write it with :, not * [08:14:46] <elenril> * is too much :effort: to write =p [08:15:20] <spaam> not on irc [08:15:36] <lu_zero> yawn [08:15:39] <lu_zero> good morning [08:16:16] <kshishkov> buon giorno [08:44:46] <lu_zero> =) [12:02:52] <Compn> heh, message i got this morning [12:02:57] <Compn> "I'm kind of in the middle of going out to buy copious amount of alcohol to celebrate Valborg (swedish spring holiday) right now, but I'll check it out when I've sobered, up in about 2 days or so." [12:03:34] <mru> those silly swedes [12:03:40] <mru> don't know how to drink properly [12:03:52] <mru> they think the entire point is getting as drunk as possible as quickly as possible [12:04:20] <kshishkov> at least it saves time [12:04:40] <kshishkov> looks like Russians to prefer to consume all possible alcohol [12:04:45] <av500> no, it makes you lose 2 days in coma afterwards [12:08:18] <kshishkov> well, Russian cure for hangover is to drink a bit more than you did before [12:10:54] <av500> rinse, repeat [13:06:18] <CIA-7> ffmpeg: ramiro * r22989 /trunk/libavdevice/vfwcap.c: vfwcap: flip RGB rawvideo. [13:28:11] <jai> "Google To Announce List Of Vendors Who Will Support VP8 On May 19th" [13:28:13] <jai> hmm [13:28:28] <kshishkov> wanna get a free kick? [13:29:53] <jai> just thought it was interesting... [13:30:18] <mru> not really [13:30:55] <Dark_Shikari> they're probably the companies on2 had already contacted before the merger [13:31:01] <kshishkov> awake us when something substantial (source code or binary and samples) will appear [13:31:04] <Dark_Shikari> and yeah, that [13:31:58] <kshishkov> I'd prefer rumours about Diablo 4 or StarCraft III to that [13:32:04] <Dark_Shikari> starcraft 2 is awesome enough [13:32:06] <Dark_Shikari> we don't need 3 yet [13:32:16] <kshishkov> not South Korea at least [13:32:18] <Dark_Shikari> speaking of which, I should go play more starcraft 2 [13:32:22] <Dark_Shikari> seriously, shit's awesome [13:32:26] <peloverde> It's good stuff [13:32:31] <mru> booooring [13:32:36] <peloverde> I finally got my key monday [13:32:52] * kshishkov reminds Dark_Shikari about TouhouCraft he's yet to write [13:32:54] <peloverde> productivity down 50% [13:32:59] <Dark_Shikari> peloverde: want to play a game? [13:33:33] <peloverde> I'm still learning the new units, maybe in a few days [13:33:39] <Dark_Shikari> wait, are you in europe? [13:33:47] <Dark_Shikari> the beta battle.net multiplayer is region-locked >_> [13:33:47] <peloverde> US [13:33:50] <Compn> construct more pylons Dark_Shikari [13:33:50] <Dark_Shikari> ok, good [13:34:02] <Dark_Shikari> peloverde: blah, it's not that hard [13:34:12] <Dark_Shikari> It helps to watch day9's daily casts though [13:34:18] <kshishkov> Compn: archon rush was better [13:34:40] * Compn having trouble finishing terran compaign in starcraft1 :P [13:34:56] <Dark_Shikari> peloverde: where did you get placed on the ladder? [13:35:19] <peloverde> In the n00b category [13:35:23] <peloverde> whatever it is called [13:35:34] <Dark_Shikari> Bronze? Silver? Gold? [13:35:41] <mru> lead [13:35:51] <peloverde> bronze [13:36:02] <kshishkov> brick! [13:36:03] <Dark_Shikari> I got put in gold for some reason, which probably means I will lose a lot [13:36:13] <Dark_Shikari> I've been winning a surprising number of games though [13:36:21] <Dark_Shikari> I won a bunch against zerg who didn't know anything except cheesing apparently [13:36:37] <Dark_Shikari> i.e. they rush you with a ton of zerglings or roaches, you barely win against them, losing half your probes.... and then you go crush them because they don't know how to play [13:37:08] <peloverde> Over in bronze land I mostly run into terran [13:37:42] <Dark_Shikari> what race do you play? [13:38:12] <peloverde> I've been switching between 'toss and terran [13:38:39] <peloverde> In SC1 I was always toss, but i kind of like the new terran air units [13:39:01] <Dark_Shikari> the air units in general are a billion times more powerful [13:39:03] <Dark_Shikari> it's not even funny [13:39:17] <Dark_Shikari> 6 void rays can completely murder you even if you have tons of anti-air [13:39:24] <Dark_Shikari> 2 void rays can ninja-kill a nexus [13:39:30] <Dark_Shikari> 3 banshees can kill all your SCVs before your army gets back [13:39:44] <Dark_Shikari> 4 phoenixes can turn the tide of a large battle by picking up the enemy's immortals [13:40:47] <peloverde> I've started putting cannons/turrets behind my minerals because of banshees killing my workers [13:40:59] <Dark_Shikari> IMO building phoenixes is a good strategy [13:41:00] <mru> geeks! [13:41:09] <Dark_Shikari> because they're not only good for anti-air, they also help in ground fights [13:41:14] <Dark_Shikari> and _you_ can go behind your opponent's mineral line [13:41:16] <Dark_Shikari> and pick up 10 SCVs [13:41:18] <Dark_Shikari> and kill them all [13:41:32] <Dark_Shikari> they serve double-duty effectively [13:43:06] <Dark_Shikari> mru: wrong response [13:43:11] <Dark_Shikari> correct response is "NEERRRRRRRRRRRRRRDDDSSSS" [13:43:50] <Dark_Shikari> http://www.youtube.com/watch?v=gZEdDMQZaCU [13:44:15] <mru> stupid film [13:53:52] <KotH> n00bish OT question: do usb wlan dongles work fine on linux? [13:54:00] <mru> some of them [13:56:34] <merbzt> most cheap new ones do [13:56:53] <merbzt> thay are based on realtek and ralink [13:56:59] <KotH> domo! [13:57:34] <mru> both realtek and ralink have a very special definition of the word work [13:57:39] <kshishkov> you can also look a list of dongles recommended for some toy running Linux (like BeagleBoard) [13:57:43] <merbzt> indeed [13:58:16] <mru> I think their definition is something like "drive the user nuts as quickly as possible" [13:58:47] <KotH> well, as soon as we get to taht point, we'll avaluate multiple dongles and select one that works [13:58:55] <kshishkov> for me Realtek = "cheap as dirt, common as dirt, good as building from dirt" [13:59:07] <twnqx> mru: i have a fun case of a computer with an intel card that just refuses to work with my AP [13:59:31] <merbzt> sometimes they put together some hardware that works properly [13:59:38] <twnqx> fun fact: if i out that card in my laptop it works, if i put my laptop's card and hdd in said comp and boot it it doesn't [14:00:17] <twnqx> funfact: with intel's v1 ucode my laptop can't connect to the AP either [14:00:43] <twnqx> i hate wlan, not only because of driver issues though [14:13:33] <Honoome> bilboed-pi: thanks, that's one of the few testsuite that actually _got fixed_ after I reported the bug ;) [14:13:42] * bilboed-pi bows [14:13:52] <bilboed-pi> it was a stupidity in fact [14:14:22] <bilboed-pi> I'd forgotten to remove that assert (was already checking in every individual test and exiting gracefully) [14:42:12] <CIA-7> ffmpeg: mru * r22990 /trunk/libavutil/bswap.h: [14:42:12] <CIA-7> ffmpeg: bswap: add macros to byteswap constants [14:42:12] <CIA-7> ffmpeg: The normal byteswap functions might use inline asm which is suboptimal [14:42:12] <CIA-7> ffmpeg: with constants (and cannot be used in static initialisers), so special [14:42:12] <CIA-7> ffmpeg: macros for constants only is needed. [14:42:12] <CIA-7> ffmpeg: We should not rely on the gcc __builtin_constant_p() test since it is [14:42:13] <CIA-7> ffmpeg: not always available. [14:54:51] <av500> http://blog.streamingmedia.com/the_business_of_online_vi/2010/04/google-to-… [14:54:53] * av500 hides [14:55:46] * kshishkov adds two kickpoints to av500's score [14:57:57] <av500> no, but question is, does anybody know anybody of the abovementioned that has been asked by gg to support vp8? [14:59:52] <kshishkov> is there anybody actually mentioned there? [15:00:17] <av500> no, but "many different vendors in the online video ecosystem including video platform providers, encoding companies, hardware vendors and other" [15:00:24] <av500> many = leaks [15:02:39] <kshishkov> that was taken from old press-release and s/On2/Google/, I think [15:03:25] <janneg> does ffmpeg count as encoding company? [15:03:35] <kshishkov> nope [15:04:13] <av500> actually, why dont we ask gg and make a stealth vp8 available on may 19th? [15:05:11] <janneg> maybe other? since all/most video plattforms are using ffmpeg it should be involved [15:05:14] <kshishkov> what, and ruin the legend? [15:05:48] <janneg> av500: don't ask google and just rebrand libx264 as vp8++ [15:06:08] <janneg> and release it on 19th [15:06:33] * mru knows something [15:07:02] <kshishkov> and? has someone cast NDA spell on you? [15:07:06] <mru> yes [15:07:14] <mru> that's all I can say [15:07:17] <mru> for now [15:07:56] <av500> just tell us one thing, is it 2x or 3x better than H264? :) [15:08:10] <mru> of course it's not better [15:08:40] <mru> it doesn't even have b-frames [15:08:52] <av500> it has GOLDEN frames! [15:08:58] <mru> and no loop filter [15:09:10] <mru> only stupid postfilters to cover up the mess [15:09:17] <Dark_Shikari> no, they have a loopfilter [15:09:33] <Dark_Shikari> it also uses non-adaptive arithcoding [15:09:40] <mru> they have loopfilter? [15:09:48] <mru> but also postfilters? [15:09:51] <Dark_Shikari> Yes [15:09:53] <Dark_Shikari> like vp3 [15:09:55] <kshishkov> look at VP3 [15:10:03] <mru> VPSNR [15:10:07] <superdump> vp8 doesn't have b-frames? [15:10:10] <Dark_Shikari> superdump: correct [15:10:19] <Dark_Shikari> vp8 is vp7 with more marketing [15:10:27] <mru> m-frames [15:10:41] <Dark_Shikari> vp7 is vp6 with more marketing and more postfilters [15:10:49] <superdump> is that like the "smoooooke" scenes in family guy? [15:11:10] <superdump> randomly inserted into your stream for better qualiteh [15:11:37] <superdump> did they fix rate control yet? [15:12:15] <superdump> i remember testing vp6 with some vfw jobby and it was shocking [15:12:46] <Dark_Shikari> probably not [16:34:04] <Compn> i hope superdump was using 2pass vp6, 1pass vp6 looks crapppp [16:38:22] <peloverde> Is there an easy way to export from spreadsheet to mediawiki, I want to publish some stuff from some of my spreadsheets [16:41:34] <iamlindoro> peloverde: http://wiki.services.openoffice.org/wiki/Odt2Wiki/Features perhaps? [16:41:59] <peloverde> hmmm, that might work [16:42:20] <iamlindoro> Not sure if it's exclusively odt, or if it'll do ods [16:44:50] <KotH> a coworker told me a few weeks ago, that oo can save to mediawiki format directly [16:45:01] <KotH> though, i've not seen it myself and havent tried either [16:47:24] <peloverde> can anyone figure out what this covers http://www.google.com/patents?vid=USPAT6075901 it seems vague and generic [16:48:39] <BBB> mru: does gcc understand "or %ecx,(%ebx, 4)"? [16:49:12] <BBB> or does the second (target) always have to be a direct register? [16:49:55] <mru> s/gcc/x86/ [16:50:05] <mru> and I don't know the answer [16:50:37] <pengvado> you mean "or %ecx, (,%ebx,4)" ? [16:51:10] <mru> eeeew, empty field [16:52:04] <pengvado> 1st field is the base register, 2nd is the index register, 3rd is the scale. any of them can be missing, but that dosen't change the positions of the remainder. [16:52:20] <BBB> pengvado: ok, well, something like that yes [16:52:36] <BBB> thanks [16:52:42] <mru> what does a missing operand even mean? [16:52:43] <BBB> and I will really learn all this some day [16:52:46] <BBB> just not today :) [16:53:11] <pengvado> yasm syntax: "or [ebx*4], ecx" [16:53:24] <Dark_Shikari> peloverde: looks like something from mpeg-4 part 2 [16:53:33] <pengvado> and it means exactly what it says. the address is ebx*4 [16:53:39] <BBB> pengvado: I actually want or [ebx+4], ecx [16:53:48] <peloverde> what is it doing in the systems portfolio? [16:53:52] <BBB> is it then (%ebx,4,1)? [16:54:12] <pengvado> gcc syntax: "or %ecx, 4(%ebx)" [16:54:20] <Dark_Shikari> peloverde: I have no idea [16:54:22] <BBB> aha [16:54:25] <BBB> ok [16:54:27] <BBB> this is retarded [16:54:31] <BBB> I'll write it in yasm from now on [16:54:37] <Dark_Shikari> yes, use yasm [16:54:43] <mru> lol @ FIG 1 in that patent [16:55:38] <mru> and yes, whatever it is, it's definitely codec, not container [17:00:51] <av500> peloverde: funny, I was looking at this one yesterday... [17:01:42] <peloverde> av500, I'm trying to debunk the myth that any of the isom/mp4ff features people actually use are patented [17:02:13] <av500> well, I was asked the same yesterday... [17:03:41] <av500> so I ended up staring at the same list of patents that you are now looking at, I guess [17:03:59] <bilboed-pi> peloverde, could only find patents for the RTP hinting parts of qtff [17:04:55] <peloverde> I've found patents for scene animation compositions, rotation on a cube, and MPEG-J [17:05:02] <peloverde> as well as the hinting [17:05:17] <peloverde> and three somewhat vague mysteries [17:06:09] <bilboed-pi> fwiw, in gstreamer we decided it was safe enough to put the qt/iso demuxer in -good (patent free) [17:07:01] <peloverde> I think the pool being disbanded is a signal that they don't cover useful things [17:07:19] <Dark_Shikari> bilboed-pi: I thought -good was just LGPL? [17:07:23] <bilboed-pi> eh ? pool disbanded ? [17:07:33] <mru> mpegla patent pool for mpeg4 systems [17:07:38] <Dark_Shikari> they disbanded it? [17:07:39] <Dark_Shikari> oh wow [17:07:39] <bilboed-pi> Dark_Shikari, good is LGPL + patent-safe [17:07:40] <av500> bilboed-pi: yes [17:08:12] <av500> maybe after nobody licensed it.... [17:08:20] <bilboed-pi> I guess the 90s are really over then :) [17:08:46] <av500> for a solid 10ys... [17:09:43] <mru> how much do you think a cd with 14496-1:2001 will fetch? [17:10:18] <peloverde> "It belongs in a museum!" [17:11:04] <av500> mru: less than my signed minix3 copy! [17:16:07] <peloverde> In the MPEG trying to spread things over an many documents as possible category, -14 still references -1 [17:21:14] <peloverde> Why do I need Java to export from OO.o to mediawiki?! [17:22:54] <mru> because java is crap [17:23:02] <mru> and people who write word processors use crap [17:23:41] <Dark_Shikari> bilboed-pi: wow. -good really is a pile of useless [17:23:48] <Dark_Shikari> just video filters basically [17:23:53] <mru> and ffmpeg is in -ugly [17:23:56] <av500> good video filters! [17:23:57] <Dark_Shikari> no, it's in gst-ffmpeg [17:24:00] <kierank> the fact that they decided to call it OpenOffice.org instead of the more palatable OpenOffice says it all imo [17:24:01] <mru> I'll never forgive them for that [17:24:01] <peloverde> I avoid OO.o whenever possible but gnumeric seems to lack a mediawiki export [17:24:09] <mru> Dark_Shikari: did they move it? [17:24:09] <Dark_Shikari> mru: that's normal... [17:24:12] <Dark_Shikari> almost NOTHING is in -good [17:24:17] <bilboed-pi> mru, it was always in gst-ffmpeg [17:24:18] <Dark_Shikari> -ugly is where EVERYTHING good goes that doesn't go in -good [17:24:28] <Dark_Shikari> what would be insulting is if they put it in -bad [17:24:45] <bilboed-pi> Dark_Shikari, -ugly is good code but either non-LGPL license *OR* patented stuff [17:24:50] <Dark_Shikari> yes, that's my point [17:24:55] <bilboed-pi> -bad is the entry point for everything [17:24:57] <Dark_Shikari> everything good ;) [17:25:00] <mru> but _everything_ is patented [17:25:13] <mru> breathing is patented [17:25:20] <kierank> genes are patented [17:25:21] <mru> or will be, when someone discovers the gene for it [17:25:54] <bilboed-pi> Dark_Shikari, virtually all the rtp/rtsp stuff is in -good for example, I wouldn't call that useless :) [17:26:04] <mru> I would [17:26:07] <Dark_Shikari> you can't do anything with it without an encoder [17:26:13] <mru> I have never used rtp and I doubt I ever will [17:26:21] <bilboed-pi> mru, then you've never used voip [17:26:23] <Dark_Shikari> mru: "I don't use it" != "it is useless" [17:26:26] <bilboed-pi> oh wait, you most likely have [17:26:36] <bilboed-pi> unless you live on Mars (which you most likely do) [17:39:22] <peloverde> If somebody feels like wasting some time they can pretty this up: http://wiki.multimedia.cx/index.php?title=MP4_File_Format_Patents [17:40:10] <av500> peloverde: all the non-US ones are the same as the US ones? [17:40:16] <av500> from the mpegla list? [17:41:00] <peloverde> Sharp has a JP one that has no US counterpart [17:41:07] <av500> lol @ the java patent [17:41:14] <peloverde> as does Mitsubishi Electric Corporation [17:41:22] <av500> they in japanese? [17:41:34] <peloverde> no idea [17:41:42] <av500> as KotH to translate... [17:41:44] <av500> ask [17:42:10] <peloverde> I don't really care about Japanese patents because I don't do business in .jp [17:44:10] <Yuvi> 5844867 seems to be vbv [17:48:00] <Yuvi> and 6091769 talks about ts only [17:51:54] <peloverde> I have a much better spreadsheet for mp3 that shows when things expire, what can be licensed from who, what patents have been tested in court what are enc only [17:53:20] <peloverde> for instance US 5214678 is dead in 31 days [17:53:34] <Dark_Shikari> how many left? [17:54:23] <peloverde> 33 are still inforce [17:54:35] <Dark_Shikari> deadline till all expire? [17:55:24] <peloverde> US 6185539 26 May 2018 but... [17:55:31] <Dark_Shikari> how is that even possible? [17:55:33] <Dark_Shikari> mp3 isn't that new [17:56:01] <peloverde> I believe that one covers MPEG-2 LSF [17:56:14] <peloverde> which nobody really cares about [17:56:59] <peloverde> Also don't forget that in the first half of the 90s all the crazy submarine rules were in effect [17:57:09] <Dark_Shikari> Yeah [17:59:15] <peloverde> US 6185539 cites itself as a modification of 13818-3:1995 [18:01:35] <peloverde> crap I forgot about US 6289308 filed 8-Mar-2000 granted 11-Sep-2001 expires 8-Mar-2020 [18:02:13] <Dark_Shikari> how the hell can they grant a patent on mp3 5 years after mp3 came out? [18:02:42] <peloverde> If you look at the actual patent it's not on mp3 [18:02:47] <Dark_Shikari> what's it on? [18:02:51] <peloverde> thompson puts it in there to scare people [18:02:54] <Dark_Shikari> lol [18:02:56] <Dark_Shikari> hhahahahaa [18:07:19] <peloverde> "The transmitter as claimed in claim 2, characterized in that the at least one auxiliary digital signal component is a third digital audio signal component." [18:08:10] <Dark_Shikari> lol [18:09:10] <av500> peloverde: which one is that? [18:09:43] <peloverde> US 6289308 owned by Philips licensed by Audio MPEG, Inc [18:11:19] <av500> ah, the padding bit one [18:11:32] <av500> good ole '308 [18:17:43] <kshishkov> wow, no onjoin message from bcoudurier [18:17:43] <Honoome> peloverde: you know with that kind of data made public you could have a âwhen will ogg stop be hypedâ site :P [18:18:01] <bcoudurier> hi guys [18:19:03] <lu_zero> Honoome: hi! [18:19:17] <peloverde> crap padding bit was subdivided into 7209565 and that's not on my list [18:19:36] <Dark_Shikari> wtf, that new a patent? [18:19:37] <Honoome> lu_zero: axant's DNS f-up? [18:19:43] <lu_zero> how so? [18:20:14] <Honoome> ah works nowâŠ for a while it didn't reach the dns [18:20:22] <lu_zero> wonderful... [18:20:32] <peloverde> Patents can be split up into smaller chunks sometimes [18:22:00] <kshishkov> claims? [18:23:18] <peloverde> '565 is here http://www.google.com/patents?vid=USPAT7209565 [18:23:31] <peloverde> but google doesnt seem to track what things were divided off of :( [18:23:50] <peloverde> USPTO: http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/ne… [18:24:00] <peloverde> see Parent Case Text [18:25:35] <kshishkov> IIRC, that's called divided claims or something [18:26:04] <peloverde> yeah [18:26:12] <peloverde> It makes tracking things so much more of a pain [18:27:42] <kshishkov> not with uspto [18:28:18] <kshishkov> and on esp@cenet they even have "patent family" search [18:29:29] <peloverde> according to phillips '565 expires 24-jun-11 [18:30:26] <peloverde> i based my mp3 spreadsheet on a k5 article that I don't think properly tacked splits [18:44:19] <wbs> bcoudurier: do you have time to have another look at Yuvi's movenc/qt chapters, patch, and my rtp hinting patches? [18:44:40] <BBB> how do I make wmavoice depende on the sin table creation function? [18:44:55] <BBB> (ff_sine_window_init()) [18:45:19] <kshishkov> look at examples in configure [18:47:01] <BBB> hm, right [18:47:02] <BBB> mdct [18:47:02] <BBB> ok [18:52:16] <BastyCDGS> hi @ all [18:52:58] <kshishkov> hi from me :P [18:53:03] <av500> BastyCDGS: what sw is/was used to create HAM images? [18:53:26] <BastyCDGS> If I remember correctly DPaint IV was able to do it [18:54:07] <kshishkov> it's all in wikipedia ;) [18:54:41] <av500> wikiwhat? [18:55:13] <kshishkov> "a source of lies anybody can spoil" [18:55:40] <av500> but what SW would I use today, not owning an amiga on life support? [18:56:09] <kshishkov> UAE of course! [18:56:26] <BastyCDGS> yes UAE ;) [18:56:42] <av500> so there is no cmdline tool? [18:56:44] <BastyCDGS> I really do not know of PC software which can do it [18:57:00] <av500> ok, so we are really beating a dead horse [18:57:02] <BastyCDGS> well I want an IFF-ILBM encoder someday for ffmpeg, too. [18:57:07] <BastyCDGS> so you have a cmdline tool then ;) [18:57:17] <av500> HAM encoder should be nice [18:57:42] <av500> so, now I installed uae, what now? [18:57:45] <BastyCDGS> but this will clearly after gsoc mod task [18:57:51] <kshishkov> IIRC, there were some powerful tools for DOS like pv or ImageAlchemy [18:57:54] <BastyCDGS> you need a kick rom [18:57:54] <av500> it wants to be kicked [18:57:58] * av500 kicks uae [18:58:01] <BastyCDGS> lol [18:58:37] <kshishkov> that's their name for firmware image [18:58:44] <BastyCDGS> what was the address of ffmpeg ftp again? [18:58:44] <av500> kshishkov: I know that [18:58:49] <BastyCDGS> then I'll upload basic UAE stuff [18:59:01] <kshishkov> available only for pirates and Amiga users :) [18:59:11] * BastyCDGS hisses pirate flag :D [18:59:29] * av500 leaves office [19:00:41] <BastyCDGS> lol [19:19:54] <_av500_> BastyCDGS: if you upload some kickfoo tell me where [19:20:47] <BastyCDGS> http://thepiratebay.org/torrent/3796333/Amiga_Kickstart_Roms_(Complete)_-_T… [19:21:23] <_av500_> toorent? that illegal, no? [19:21:50] <BastyCDGS> depends on your country [19:22:08] <BastyCDGS> here in belgium no one cares about such stuff [19:22:39] <_av500_> ill torrent it from the office tomorrow [19:24:30] <BastyCDGS> the copyright industry probably didn't enough deliver black suitcases to the politicians here yet ;) [19:28:22] <Rathann> torrent isn't illegal [19:28:56] <Rathann> distributing content which you have no right to distribute is [19:38:06] <peloverde> wow https://www.ip.philips.com/download_attachment/5781/Video_CD_Player_Video_C… totally has sooner expirations for almost all the philips patents than what was in the k5 article [19:44:32] <peloverde> That said '308 is not on the VCD list, but i'm inclined to think it should be the same as '565 [19:54:41] <_av500_> peloverde: some of our players would totally ignore the padding bit in mp3 [19:55:38] <peloverde> If the padding bit is indeed now split into 7209565, that expires summer 2011 [20:08:55] <peloverde> wtf https://www.ip.philips.com/download_attachment/5781/Video_CD_Player_Video_C… and https://www.ip.philips.com/download_attachment/297/297.pdf list different expirations on the same patents [20:09:35] <_av500_> i would not list exp dates for my own patents [20:11:02] <peloverde> It *should* be the PTOs job to compute and list expiration dates [20:11:53] <BBB> since when are we interested in patents? [20:12:25] <peloverde> since people started blathering on about mp4ff being encumbered [20:12:38] <Dark_Shikari> since peloverde started whining [20:14:26] <peloverde> It's ridiculous that Philips can't seem to agree with itself on the expiration dates of its own patents [20:15:49] <BBB> holy shit g++ is slooooooooooooow [20:15:59] <BBB> I started compiling this wrapper lib about 3 hours ago [20:16:03] <BBB> IT'S STILL COMPILING [20:16:16] <peloverde> just wait until you get to linking [20:16:31] <BBB> wtf is wrong with this thing [20:17:07] <BastyCDGS> BBB, one question [20:17:10] <BastyCDGS> for (i=0; i < count; i++) { [20:17:10] <BastyCDGS> s->ham_palbuf[i] = AV_RL24( avctx->extradata + i*3 ); [20:17:10] <BastyCDGS> } [20:17:15] <BastyCDGS> I need a AV_RN24 here [20:17:18] <Dark_Shikari> BBB: C++! [20:17:22] <BBB> BastyCDGS: go for it :) [20:17:26] <Dark_Shikari> I heard you like undecidable grammars [20:17:29] <BBB> BastyCDGS: afaik we have a 24 one [20:17:57] <BBB> BastyCDGS: libavutil/intreadwrite.h:# define AV_RN24(p) AV_RB24(p) [20:18:07] <BBB> (this is a grep, so there's probably an #ifdef BE above it) [20:18:33] <BBB> but uh, why do you need a AV_RNxx? [20:18:35] <BastyCDGS> I just got this mail: [20:18:40] <BastyCDGS> > Could you try to change AV_RL32 (not AV_RB32 !!!) in cmap_read_palette: [20:18:40] <BastyCDGS> > > s->ham_palbuf[i] = AV_RL24( avctx->extradata + i*3 ); [20:18:40] <BastyCDGS> > > to: [20:18:40] <BastyCDGS> > > s->ham_palbuf[i] = AV_RN24( avctx->extradata + i*3 ); [20:18:40] <BastyCDGS> > > [20:18:41] <BastyCDGS> > > And tell me if it fixes all HAM related bugs? If symbol not found on [20:18:41] <BastyCDGS> > > linking, do AV_RN24A... [20:18:41] <BBB> I mean, this thing has a particular byte order right? [20:18:42] <BastyCDGS> [20:18:42] <BastyCDGS> I get undefined symbols with AV_RN24 and AV_RN24A. Any other suggestion? :P [20:19:03] <BBB> #include <intreadwrite.h> [20:19:08] <BBB> or so [20:19:14] <BBB> "libavutil/intreadwrite.h" [20:19:18] <BastyCDGS> the other macros work [20:19:52] <BastyCDGS> btw, what you think we should use now for dp8? [20:20:01] <peloverde> ps for anyone following on e-mail it turns out that the second links is from 2001 and has been corrected [20:20:04] <peloverde> mystery solved [20:20:05] <BastyCDGS> uint64_t and 8 bit table or uint32_t and 4 bit table? [20:20:14] <BastyCDGS> 8 bit is 6000 cycles and 4 bit is 8000 cycles [20:20:21] <BastyCDGS> with my athlon XP+ 2100 [20:20:41] <BastyCDGS> btw, I created the 8 bit table and it works ;) [20:20:48] <BastyCDGS> but it's 256 lines just of init [20:20:50] <BastyCDGS> a bit large [20:21:02] <BBB> 8bit is ok [20:21:09] <BBB> and wrap the lines [20:21:12] <BBB> don't do one value per line [20:21:18] <BastyCDGS> yes that was what I did [20:21:20] <BBB> learn to write efficient (line-compact) macros :) [20:21:23] <BastyCDGS> that's why it's 256 lines ;) [20:21:25] <BBB> 256 lines is too much [20:21:38] <BastyCDGS> well I could do: [20:21:42] <BBB> I don't understand intreadwrite.h at all [20:21:42] <BBB> a [20:21:43] <BBB> s [20:21:43] <BBB> [20:21:46] <BBB> ask mru [20:21:58] * BBB kicks irc client [20:22:03] <BBB> this client is really screwed up [20:22:03] <BastyCDGS> #define LUT8(plane) { \ [20:22:03] <BastyCDGS> 0x000000000000000ULL << plane, \ [20:22:03] <BastyCDGS> usw. [20:22:10] <BastyCDGS> thats what I did now [20:22:14] <BastyCDGS> changing this to: [20:22:45] <BastyCDGS> #define LUT8(h_plane,l_plane) { \ [20:22:45] <BastyCDGS> (0x00000000 << h_plane) | (0x00000000 << l_plane), \ [20:22:55] <BastyCDGS> l_plane << 32 [20:23:04] <BBB> send me the patch [20:23:06] <BBB> I'll look [20:23:10] <BBB> but not now, /me busy ;) [20:23:24] <BastyCDGS> btw, I shouldn't do 0x000000001010101000ULL right? [20:24:47] <BastyCDGS> wasn't there a DECLARE_64 macro or sth. like that? [20:24:57] <BastyCDGS> after all I should use the new macros from mru, right? [20:28:02] <BastyCDGS> btw, what's the difference between av_const and normal const qualifier? [20:28:30] <_av500_> aaargh: http://pastebin.com/0wH2ZnYR [20:33:17] <BastyCDGS> so now how do I correctly define uint64_t constants? [20:33:28] <BastyCDGS> I remember there was sth. I shouldn't do ULL or LL qualifiers [20:34:50] <Dark_Shikari> ULL [20:35:11] <BastyCDGS> wasn't there someone here yesterday just wanted to do this? [20:35:16] <BastyCDGS> suse patch, reddwarf [20:44:30] <BastyCDGS> hope this is fine [20:44:31] <BastyCDGS> AV_LE2ME64C(0x101010100000000ULL << plane), \ [20:48:28] <peloverde> does multimedia wiki support any sort of footnotes? I can't get <ref> to work [20:58:07] <BBB> BastyCDGS: UINT64_C(xx) [20:58:30] <BBB> BastyCDGS: don't use ULL/LL, youre not defining a longlong, you're defining a 64-bit int, whatever short/long that is [21:00:06] <BastyCDGS> thx [21:01:58] <BastyCDGS> AV_LE2ME64C(UINT64_C(0x000000000000000) << plane), \ [21:02:41] <_av500_> ME is middle endian? [21:03:02] <BastyCDGS> dunno why mru tool ME instead NE [21:03:05] <BastyCDGS> took [21:04:59] <BastyCDGS> it's a static table depending on target endianess [21:05:11] <BastyCDGS> otherwise my heavy opt patch doesn't work for big endian CPUs [21:05:42] <Rathann> I guess it means machine-endian, but native-endian is more common, isn't it? [21:05:44] <_av500_> i know [21:06:02] <_av500_> BastyCDGS: i know [21:06:05] <_av500_> damn lag [21:06:12] <BastyCDGS> ok ;) [21:06:28] <BastyCDGS> we're using NE on other parts of src... [21:06:43] <BastyCDGS> or just N [21:08:21] <BastyCDGS> btw, anyone compiling on x86_64 here? [21:08:31] <Rathann> OTOH, there are some macros using me already there [21:08:37] <Rathann> BastyCDGS: I am, why? [21:09:00] <BastyCDGS> just want to see how decodeplane8 asm output with new 8 bit table on x86_64 looks ;) [21:09:08] <Rathann> ah [21:09:23] <Rathann> well, I'm running a semi-automated build of my RPM package [21:09:30] <BastyCDGS> I will submit the patch soon, just compiling ffmpeg [21:10:09] <BastyCDGS> it has to rebuild everything since bswap.h just changed [21:10:40] <_av500_> that takes 30s :) [21:10:54] <BastyCDGS> here it takes 2-3 mins [21:16:45] <peloverde> taadaa! http://wiki.multimedia.cx/index.php?title=MP3_Patents [21:17:09] <_av500_> peloverde: \\\ooo/// [21:18:09] <_av500_> damn 2018 [21:25:28] <peloverde> people may be able to correct those dates or pin them as non essential [21:25:35] <peloverde> that's the point of putting it in the wiki [21:26:03] <peloverde> people sued to cite 2020 based on 6289308, so 2018is an improvement [21:29:20] <pJok> so mp3 will be patent free in 2017? [21:29:36] <pJok> err, 2018 [21:30:16] <pJok> fun [21:32:05] <BastyCDGS> gmail server is crazy submitting patch [21:32:13] <BastyCDGS> hangs for almost a minute on 67% and then aborts [21:32:27] * pJok calls Thomson for MPEG patent trolls [21:32:53] <BastyCDGS> you mean those Thomson doing mp3PRO? [21:33:09] <BastyCDGS> btw, really would like a linux decoder for mp3PRO format [21:33:25] <BastyCDGS> there's a hack getting the winamp plugin for it to work on XMMS [21:33:33] <BastyCDGS> but it's really ugly and often crashes or doesn't work [21:33:52] <pJok> patch welcome ;) [21:34:44] <BastyCDGS> would be pretty hard, as far as I know this format has to be reverse engineered there's no official format description [21:35:24] <BastyCDGS> patch for dp8 sent [21:35:35] <BastyCDGS> did it using my fh-aachen.de mail server [21:36:09] <peloverde> BastyCDGS, the mp3pro xmms plugin has full debugging symbols and uninlined get_bits calls [21:36:17] <pJok> its just standard mp3 with SBR [21:36:18] <pJok> http://wiki.multimedia.cx/index.php?title=MP3 [21:37:12] <peloverde> The SBR and PS formats did evolve during standardization, it is possible that the bitstream format for the SBR data is slightly different [21:37:13] <BastyCDGS> but the mp3pro xmms plugin uses winamp dll [21:37:53] <peloverde> no it doesn't [21:38:05] <pJok> peloverde, use a bigger hammer ;) [21:38:09] <peloverde> libmp3PRO.so [21:38:29] <BastyCDGS> Your mail to 'ffmpeg-devel' with the subject [21:38:29] <BastyCDGS> [21:38:29] <BastyCDGS> Re: [FFmpeg-devel] [PATCH] Fix non-rounding up to next 16-bit [21:38:29] <BastyCDGS> aligned bug in IFF decoder [21:38:29] <BastyCDGS> [21:38:30] <BastyCDGS> Is being held until the list moderator can review it for approval. [21:38:31] <peloverde> either way with full symbols and function calls for get_bits it should be trivial [21:39:35] <peloverde> BastyCDGS, if you want to RE it, i'll be glad to help with the actual SBR algorithms [21:40:01] <BastyCDGS> well I want this, but I'm afraid I've enough to do with the IFF stuff right now and gsoc task ist mod stuff [21:40:21] <bcoudurier> non member [21:40:26] <bcoudurier> subscribe [21:40:42] <bcoudurier> Reason: Post by non-member to a members-only list [21:41:09] <BastyCDGS> I had to write from different mail address [21:41:15] <BastyCDGS> will just try gmail again [21:43:09] <BastyCDGS> damn [21:43:11] <BastyCDGS> http://pastebin.org/193197 [21:43:16] <BastyCDGS> can someone review it this way plz? [21:46:32] <peloverde> "+ const unsigned plane)" [21:46:42] <peloverde> why does that need to be const or unsigned? [21:47:15] <peloverde> if someone gives you -1 you are trading a backward ref for something way past the end [21:47:24] <BastyCDGS> plane is always >= 0 [21:47:48] <BastyCDGS> also plane is always between 0 <= plane <= 24 [21:47:53] <BastyCDGS> the demuxer/decoder checks that [21:47:58] <BastyCDGS> < 24 [21:48:06] <peloverde> so what is the advantage to using unsigned? [21:48:33] <BastyCDGS> it does convert automatically a 2^n div to >> n [21:48:42] <peloverde> the problem with unsigned is at somepoint down the road it might bite someone in the ass in regard to an integer promotion bug [21:49:05] <peloverde> it never divides by plane [21:49:15] <peloverde> it's only used in "const uint64_t *lut = plane8_lut[plane];" [21:49:43] <peloverde> and the unsigned thing did bite me in the ass all over the place in superdump's sbr code [21:49:51] <BastyCDGS> btw, gmail sending works again...patch is now on ml [21:50:34] <bcoudurier> BastyCDGS, do you want me to approve it nonetheless ? [21:50:50] <BastyCDGS> of course [21:51:19] <BastyCDGS> pelo i don't have any problems with unsigned...in fact that's what I hate with java, no unsigned except word size [21:51:24] <peloverde> "value << signed_int_var" is perfectly acceptable as long as signed_int_var is in the proper range [21:53:04] <peloverde> unsigned is useful but unless it's actually serving a purpose it's just clutter [21:53:22] <peloverde> I don't see the purpose in plane being unsigned [21:56:16] <BastyCDGS> greaaaaat! [21:56:26] <BastyCDGS> gmail has fixed the issue that sent mails are now come back! [21:56:42] <BastyCDGS> my patch was just echoed to me :) [21:57:28] <bcoudurier> approved [21:59:50] <BastyCDGS> well passing a negative plane value to dp8 is an error! [22:00:03] <BastyCDGS> and to clarify this to the programmer I declared this as unsigned [22:00:49] <_av500_> that wont stop them [22:01:41] <BastyCDGS> the function is called in a for loop from 0...number of planes - 1 which is also unsigned [22:02:22] <BastyCDGS> if number of planes == 0 the for loop isn't executed at all [22:02:36] <BBB> it doesn't matter [22:02:43] <BBB> it's always in the range of [0,7] [22:02:45] <BBB> or so [22:02:53] <BBB> so it doesn't make sense to discuss unsignedness [22:02:55] <BBB> the code won't change [22:03:05] <BBB> (the generated asm) [22:03:09] <BastyCDGS> yes but it won't hurt either to keep it unsigned [22:03:19] <BBB> well, the elementary basic counter type is int [22:03:21] <BBB> so we use int [22:03:32] <BBB> for (int i = 0; i < 10; i++) printf("%d\n", i); [22:03:36] <BBB> people don't use unsigned [22:03:39] <BBB> it might be optimal [22:03:41] <BBB> but they don't [22:03:49] <BBB> probably because int is shorter to type than unsigned [22:04:01] <BastyCDGS> no unsigned == unsigned int [22:04:19] <BastyCDGS> oh you mean typing chars not size [22:04:37] <BBB> yes [22:04:48] <BBB> you're gaining 5 chars there [22:04:56] <BBB> assuming there's about 10-100 per codec [22:05:02] <BBB> and we have like what, 80 codecs? [22:05:05] <BBB> let's assume 25 on average [22:05:10] <BBB> that's 80x25x5 bytes less code [22:05:21] <kierank> lol [22:05:22] <BBB> that's 10kB right there [22:05:28] <BBB> \o/ [22:05:41] <BBB> imagine how much faster that tarball just flows through the pipes onto your harddisk [22:05:41] <BastyCDGS> well you have accepted my patch changing int to unsigned quite a time ago ;) [22:06:00] <BBB> right, but Michael asked me to revert the ones that make no difference [22:06:03] <BBB> I'm working on that :-p [22:06:14] <BBB> in general, stick to int [22:06:29] <BastyCDGS> but these made a difference there were some mults and divs which weren't converted to shifts ;) [22:06:35] <BBB> some made a difference [22:06:36] <BBB> not all [22:06:57] <BastyCDGS> btw, changing some of those to int fails the HAM decoder [22:07:38] <BBB> ? [22:07:38] <BastyCDGS> mixing unsigned and signed stuff should also be avoided some CPUs generate an extra instruction in these case [22:08:43] <BastyCDGS> unsigned char a = 3; [22:08:43] <BastyCDGS> int b; [22:08:43] <BastyCDGS> b = a; [22:09:07] <BastyCDGS> on m68000: [22:09:07] <BastyCDGS> moveq #3,d0 [22:09:07] <BastyCDGS> ext.w d0 [22:09:07] <BastyCDGS> ext.l d0 [22:09:25] <BastyCDGS> (I left out the move to d1) and doing ext.w d1, ext.l d1 [22:09:44] <BastyCDGS> also zero extend is often faster than signed extension [22:10:10] <BastyCDGS> and yes, ffmpeg does run on m68k amiga [22:10:20] <BastyCDGS> the polish guy submitting the bad IFFs just uses it on m68k amiga [22:10:35] <peloverde> uint8/16_t tables are fine [22:10:53] <BastyCDGS> yeah and putting them to an int to local will just cause the above ;) [22:11:59] <peloverde> unsigned on a regular scalar variable is silly unless you are purposely trying to exploit the the type promotion or dividing it by something [22:12:29] <BastyCDGS> yes but often you don't know in advance if you have to divide sth. [22:12:36] <BastyCDGS> also signed multiply is also slower sometimes than unsigned [22:12:55] <BastyCDGS> and the worst thing is [22:13:09] <BastyCDGS> using signed keeps the compiler from optimizing to rol/ror [22:13:17] <BastyCDGS> gcc can do: [22:13:28] <BastyCDGS> unsigned a = (b << 15) | (b >> 17) [22:13:35] <BastyCDGS> and replace this with and rol/ror instruction [22:13:42] <BastyCDGS> but not if either a or b are signed [22:14:46] <BastyCDGS> and because people tend to use int rather unsigned stuff like 2GB limit on files on FAT happens instead 4GB [22:15:31] <BastyCDGS> and read the IFF specs, they also say what has to be signed...amiga clearly makes advantage of such stuff [22:15:38] <peloverde> have you ever heard of catchconv? [22:15:40] <BastyCDGS> number of planes is UBYTE [22:16:08] <peloverde> it's a smart fuzzer that originally found security bugs solely based on signed/unsigned promotion [22:16:11] <BastyCDGS> catchconv? [22:16:40] <peloverde> yes catchconv [22:16:52] <BastyCDGS> ok another example: [22:16:52] <BastyCDGS> array indices, check bounds: [22:16:52] <BastyCDGS> some people do if (index < 0) || (index > max_index) [22:17:09] <BastyCDGS> changing to unsigned yields: [22:17:10] <BastyCDGS> if (index > max_index)... [22:17:12] <BastyCDGS> finish [22:17:31] <peloverde> That happens all over ffmpeg [22:17:45] <peloverde> bu doing "if (a > 10U)" [22:17:55] <peloverde> all the benefits and a can remain signed [22:18:18] <BastyCDGS> I know of compilers which require both be unsigned to actually do an unsigned comparision [22:18:43] <peloverde> that is what they are supposed to do [22:19:11] <BastyCDGS> not sure for me that sounds undefined...i.e. the compiler can decide [22:19:30] <peloverde> no it is defined [22:19:33] <peloverde> and it is all over ffmpeg [22:19:37] <BastyCDGS> where? [22:19:52] <BastyCDGS> I just know that almost all amiga compilers do this the way I described above [22:21:12] <peloverde> also is far as rorl goes: http://pastebin.com/yAn4F4rM [22:21:54] <peloverde> http://git.ffmpeg.org/?p=ffmpeg&a=search&h=834d1413d417890973e0aedb25440c23… [22:24:32] <peloverde> also libavformat/nutdec.c:266 [22:24:35] <BastyCDGS> http://yarchive.net/comp/ansic_broken_unsigned.html [22:25:23] <BastyCDGS> ... in which the result of widening any narrow unsigned type was [22:25:23] <BastyCDGS> `unsigned int'. In ANSI C, it is either int or unsigned int, [22:25:23] <BastyCDGS> depending on the implementation. [22:25:27] <peloverde> dv.c:831 [22:25:46] <BastyCDGS> unsigned short s = ~(unsigned)0; [22:25:46] <BastyCDGS> int i; ... [22:25:47] <BastyCDGS> if (i < s) [22:25:47] <BastyCDGS> [22:25:53] <BastyCDGS> In ANSI C, it sometimes means: [22:25:54] <BastyCDGS> [22:25:54] <BastyCDGS> if ((unsigned int)i < (unsigned int)USHRT_MAX) [22:25:54] <BastyCDGS> [22:25:54] <BastyCDGS> but sometimes it means: [22:25:54] <BastyCDGS> [22:25:54] <BastyCDGS> if ((signed int)i < (signed int)USHRT_MAX) [22:26:02] <BastyCDGS> that's exactly what I was saying ;) [22:26:07] <peloverde> I'm going to trust the spec over 13 year old ML post [22:26:29] <peloverde> and we already relay on the behavior anyway [22:27:04] <BastyCDGS> this is ANSI C spec [22:27:19] <BastyCDGS> maybe they fixed it in C99 [22:28:37] <BastyCDGS> btw, when you are going to convert ints to float you should use signed, since that's faster [22:28:37] <peloverde> Which of these occurs depends on the relative sizes of short and int. [22:28:38] <peloverde> If short is shorter than int, it means the latter; if short is the [22:28:38] <peloverde> same length as int, it means the former. [22:28:47] <peloverde> from that very email [22:29:07] <peloverde> even in ANSI C [22:29:09] <BastyCDGS> yes, but when you use such stuff in a macro you often don't know which type is longer or shorter [22:29:32] <peloverde> that's why you should make your variables int unless you have a good reason not to [22:29:38] <BastyCDGS> and I really find it less error prone just stick to unsigned when all values are anyways >= 0 than mixing them and getting such surprises [22:29:57] <BastyCDGS> as said amiga formats use unsigned very often and consistently [22:30:12] <BastyCDGS> since I'm dealing with amiga formats not doing so will cause hard to find bugs [22:32:02] <BastyCDGS> almost all data fields in IFF-ILBM etc. are unsigned [22:32:45] <BastyCDGS> btw, I also found out that many compilers add unnecessary & 0x7FFFFFFF stuff or sth. like that or even >> 31 when dealing with unsigned or signed [22:32:57] <BastyCDGS> esp. when mixing them [22:33:22] <peloverde> I already showed you a mixed example and all three came out identical [22:34:49] <BastyCDGS> but your third sample is wrong where all are signed [22:35:17] <BastyCDGS> signed right shift adds signed bit from the left which ror doesn't [22:35:24] <BastyCDGS> that's definitively a gcc bug [22:35:37] <peloverde> it's not a bug [22:35:45] <peloverde> they cast to unsigned for that operation [22:36:13] <BastyCDGS> oh yes I overseen this [22:36:24] <BastyCDGS> but instead writing the casts why don't pass unsigned directly [22:36:27] <BastyCDGS> that's even more to type ;) [22:37:00] <peloverde> because you may want to derive that from some sort of signed computation [22:37:03] <peloverde> also consider r21103 which fixed a real bug [22:37:45] <peloverde> or r20014 which is better explained [22:38:16] <BastyCDGS> I know that you can trigger bugs with that [22:38:26] <BastyCDGS> but as said, I'm dealing here with amiga stuff [22:38:36] <BastyCDGS> and these formats have clearly specs according to this [22:38:45] <peloverde> and it works equally well with signed! [22:39:05] <BastyCDGS> nope as already said using signed breaks HAM decoding [22:39:07] <peloverde> all you've done is split up a one line declaration into 4 [22:39:08] <BastyCDGS> I tried that out [22:39:24] <peloverde> int plane works jsut as well as unsigned plane [22:39:51] <peloverde> sure replacing all occurances of unsigned might break something but no one is asking you to do that [22:40:03] <peloverde> just to only use it when you need it [22:40:18] <BastyCDGS> int plane can make a difference in asm output depending on the target CPU [22:40:34] <BastyCDGS> on m68k it will create 2 unnecessary instructions when accessing lut [22:41:19] <BastyCDGS> just because it doesn't change anything for YOUR cpu doesn't mean it won't change anything at all [22:41:37] <BastyCDGS> on other CPUs [22:43:39] <BastyCDGS> the reason is that the m68k has to extend it for lut access [22:43:48] <BastyCDGS> I think PPC is similar to this also [22:54:04] <peloverde> I see I instruction of difference in the LLVM IR [22:55:04] <peloverde> and that's only because sizeof(intptr_t) == 8 on their demo machines [22:57:04] <peloverde> and dropping the const I see zero difference [22:57:52] <peloverde> in LLVM IR not x86 asm [23:01:36] <BastyCDGS> where you see no diff at all? [23:01:56] <peloverde> between "unsigned" and "const unsigned" on plane [23:02:24] <BastyCDGS> const just means that the value should not change in the function [23:02:40] <BastyCDGS> it's a compiler and programmer hint [23:02:50] <peloverde> yes but it's part of the reason why you've turned a one line declaration into 6 [23:03:50] <BastyCDGS> I had the discussion about this with BBB/mru already [23:04:01] <BastyCDGS> mru doesn't care and BBB said when he doesn't care we'll keep it [23:04:14] <peloverde> I'm just glad you aren't busy destroying any formats I care about [23:04:50] <BastyCDGS> well for other formats I can't speak and I wouldn't fiddle there anyway changing signed/unsigned stuff [23:04:56] <BastyCDGS> or const [23:06:30] <BastyCDGS> but where I can speak is amiga formats and I know how the amiga expects and handles things [23:06:47] <BastyCDGS> you know the original IFF decoder was very buggy because it wasn't conforming to IFF specs [23:08:50] <peloverde> It is possible to fix things without maxing the file twice as long with new decorators [23:17:24] <BastyCDGS> yes, but on the other hand it increases readibility [23:17:32] <BastyCDGS> that's what mru complained in the beginning [23:17:44] <BastyCDGS> both const and unsigned increase readibility [23:17:58] <BastyCDGS> because on both cases you know better what values are allowed and what not [23:18:20] <BastyCDGS> const tells you, don't touch this after init it will trigger side effects [23:18:50] <BastyCDGS> well I suggest for now, going to bed and just we two sleep a night about it ;) [23:21:42] <BastyCDGS> so I wish you a good night and nice dreams

1 0

IRC log for 2010-04-28
by irc＠mansr.com 29 Apr '10

29 Apr '10

[00:00:56] <BBB> there's more wrong with his response [00:01:01] <BBB> but I'm sure that'll be a nice flamewar [00:01:04] * BBB goes home [00:03:52] <iive> of course there is... but.... this is .... [00:24:15] <saintdev> i like the /. comment "Of course the DESIGNER sees no problems with the format." [00:26:34] <bcoudurier> monty has his head in his ass [00:26:51] <bcoudurier> obviously he covered his ears when people were speaking of smooth streaming [00:27:05] <bcoudurier> I mean you can stream mp4 [00:27:12] <bcoudurier> it's new [00:27:22] <bcoudurier> like the "skeleton" crap he finds excuse with [00:28:27] <mru> back [00:28:29] <bcoudurier> each line you read, the more crap you read [00:28:41] <mru> anything happen? [00:28:44] <bcoudurier> wtf is he talking about MTU and ogg pages spanning udp pakets [00:28:54] <bcoudurier> man, TS was designed to go over _sattelite_ [00:28:57] <mru> yeah, he lost me there [00:34:59] <bcoudurier> also I don't understand why ogg requires the pages 0 to be headers for codecs [00:35:09] <bcoudurier> when it is so much design around streaming [00:35:16] <mru> nobody understands anything about ogg [00:35:20] <bcoudurier> this doesn't make sense [00:35:48] <mru> none of it does [00:36:38] <bcoudurier> well he can try as much as he want to justify the "granule" thing [00:36:42] <bcoudurier> it was a stupid idea [00:37:27] <bcoudurier> storing the frame duration, and a "resync" timestamps would be a good idea IMHO [00:38:14] <Yuvi> I don't really like storing the frame duration unless it's semantically impossible to write it wrong [00:38:17] <Yuvi> like in mp4 [00:38:45] <mru> frame duration is only useful when it doesn't last until the next frame begins [00:38:48] <mru> e.g. subtitles [00:38:56] <mru> for video it's pointless [00:39:30] <bcoudurier> frame duration is the most compact way [00:39:42] <bcoudurier> that's why mp4 has so low overhead [00:39:51] <bcoudurier> basically all timestamps are compressed to one [00:40:20] <Yuvi> for cfr. with vfr it doesn't gain much [00:40:29] <bcoudurier> indeed [00:40:33] <bcoudurier> who does vfr ? [00:40:45] <Yuvi> anime mainly [00:40:53] <bcoudurier> everything is cfr except the crap your phone records [00:40:55] <bcoudurier> anime is cfr [00:41:05] <bcoudurier> it is _broadcasted_ in cfr [00:41:24] <bcoudurier> so unless you find the original copy in the studio [00:41:29] <bcoudurier> which _may_ be vfr [00:41:32] <Yuvi> no, there's a ton of mixed 24/30 where cgi is 30 and the rest is 24, or overlay is 30, etc [00:41:47] <bcoudurier> wtf are you talking about [00:42:04] <bcoudurier> in your head [00:42:43] <iive> bcoudurier: telecine [00:42:55] <bcoudurier> telecine is cfr [00:43:21] <iive> yes, but the broadcast mixex telecined and progressive content [00:43:38] <iive> when you remove the telecine, you end up with different framerate [00:43:51] <bcoudurier> different does not mean variable [00:44:05] <bcoudurier> technically :> [00:44:36] <bcoudurier> besides no broadcaster nor theater [00:44:41] <bcoudurier> supports mixed framerates [00:45:20] <iive> well, if format doesn't allow change of framerate then you need to use format with vfr [00:45:51] <iive> or worse, use common divider, like these 120fps avi. [00:46:51] <Yuvi> it's also not too hard to decimate the duplicate frames to get the original fps given how clean dtv is [00:47:38] <bcoudurier> what broadcaster do duplicate frames ? [00:47:44] <Yuvi> studio [00:48:02] <Yuvi> if it's drawn at say 12 fps [00:48:08] <mru> fairly long sections each with internally constant frame rate are also stored efficiently in mp4 [00:48:24] <bcoudurier> for anime ? yes, but that is still cfr [00:48:28] <mru> you'd never have "randomly" variable frame rates [00:49:04] <bcoudurier> and for audio it's always compressed [00:49:20] <bcoudurier> except for vorbis though hehe [00:49:38] <Yuvi> eac3, flac, and dca allow for varying frame sizes too [00:50:40] <Yuvi> but yeah, mp4 storing only duration works well for essentially all content [00:51:17] <bcoudurier> is that used in practice ? [00:51:26] <bcoudurier> our flac encoder uses fixed frame size [00:51:41] <Yuvi> I thought flake used it, which is basically our encoder [00:53:00] <Yuvi> flake does, guess ours doesn't though [00:53:05] <bcoudurier> doesn't seem to be changed during encode_frame [00:54:29] <bcoudurier> well and I hope this is not too common, otherwise mkv becomes a real nightmare [00:55:56] <Yuvi> amendment: essentially all content minus subtitles [00:56:14] <Yuvi> forgot that those are a bit annoying in mp4 [00:56:48] <bcoudurier> I agree [00:56:56] <bcoudurier> but where are they not annoying ? [00:57:16] <mru> dvd subtitles are easy [00:57:31] <mru> dvb are nightmare [00:57:41] <bcoudurier> how does dvd store displaying duration ? [00:57:58] <mru> in the payload [00:58:12] <mru> since obviously the PS layer can't do it [00:58:18] <bcoudurier> indeed [00:58:38] <bcoudurier> I thought dvb was 2 packets, like display, stop [00:59:07] <bcoudurier> how does mkv do btw ? [00:59:07] <mru> dvb has a horrible system with multiple overlapping windows, custom glyphs and god know what else [00:59:13] <Yuvi> mkv is easy for muxing, demuxing can be annoying depending on how hard you want to look for them or your system doesn't support overlapping subtitles [00:59:13] <mru> which is stupid [00:59:34] <mru> because in reality nobody uses anything more than one rectangular window anyway [01:00:19] <bcoudurier> mkv_write_ass_block looks scary to me [01:00:56] <Yuvi> cause they stripped the redundant bits out of the ass line and added a new one so that the original ass file can be recovered exactly [01:01:58] <bcoudurier> also how do you mux them in mkv, do you use the same mechanism as audio ? [01:02:03] <bcoudurier> like packed frames into a bloc [01:02:21] <Yuvi> no, one event per block, and a mandatory duration [01:02:50] <bcoudurier> seems pretty straight forward [01:03:29] <Yuvi> the trick is that start time+duration can be much greater than the next subtitle's start time (and often is) [01:04:40] <bcoudurier> yes [01:05:00] <bcoudurier> for mp4 I would store stts as the delta between sbus timestamps [01:05:07] <bcoudurier> and store display duration as well [01:05:29] <Yuvi> sbus? [01:05:47] <bcoudurier> subs [01:05:50] <Yuvi> ah [01:06:11] <Yuvi> I know quicktime only allows stts to be the duration for subs [01:06:14] <Yuvi> so no overlapping events [01:06:31] <Yuvi> and no ending before the stts duration [01:06:39] <bcoudurier> yes [01:07:09] <bcoudurier> no ending before > [01:07:15] <bcoudurier> ? huh that's odd [01:07:26] <Yuvi> and it also doesn't like discontinuous subtitle events from edts [01:07:45] <bcoudurier> huh that's fucked [01:08:00] <Yuvi> yeah, it treats the entire sample as basically a static image [01:08:23] <Yuvi> except for closed captions [01:09:19] <Yuvi> the no discontinuous events is more that it doesn't tell the renderer to do stuff until too late, so it freezes for a half second on each new sub [01:09:43] <bcoudurier> buggy [01:12:29] <Yuvi> so basically you just have to have a blank sample instead of no sample [01:27:00] <ramiro> great. I had to shut down 3 virtual boxes to have enough ram to compile one c++ file. it took 21% of the system's 4gb of memory... [01:27:39] <hyc> it's c++, is that so surprising? [01:27:47] * hyc sticks to C [01:28:00] <mru> is that all it took? you lucky bastard... [01:36:28] <mru> slashdot is depressing [01:37:38] <Yuvi> reddit doesn't like you either [01:39:50] <mru> any sensible comment gets flagged as troll [01:40:10] <hyc> yeah, I pretty much had to stop commenting [01:40:52] <hyc> I'm the leading authority in the software fields in which I work. nobody else, on slashdot or anywhere, has any business rating the correctness of my statements. [02:38:08] <ramiro> hmm, who exactly calls collect2, and who calls ld? [02:39:33] <mru> gcc -> collect2 -> ld [02:39:47] <mru> collect2 is mostly a wrapper around ld [02:41:00] <ramiro> and gcc reads the specs to choose which flags to pass to collect2? [02:41:14] <mru> guess so [02:41:23] <mru> it's a bit shrouded in mystery [02:41:32] <mru> gcc devs like it that way [02:41:42] <ramiro> heh [02:42:09] <mru> makes it harder to interface third-party tools to it [02:42:18] <mru> like, heaven forbid, a proprietary linker [02:42:47] <peloverde> or even a gnu linker rewrite :) [02:42:52] <hyc> collect2 was only introduced because of g++ [02:43:10] <mru> what's special there? [02:43:24] <hyc> if you didn't have to worry about stupid C++ constructors and destructors, there would be no need for collect2 [02:44:09] <Kovensky> <@ramiro> great. I had to shut down 3 virtual boxes to have enough ram to compile one c++ file. it took 21% of the system's 4gb of memory... <-- I can't compile firefox here, g++ hits an ICE because cc1plus gets ENOMEM after allocating the world on one file [02:44:40] <mru> compiling firefox is all but impossible on my laptop [02:44:48] <mru> starts swapping like crazy [02:44:58] <Kovensky> I tried giving more swap [02:45:06] <Kovensky> but then I just lost communication to the box and had to hard reboot it [02:45:10] <mru> I need a new laptop [02:45:18] <ramiro> or more ccache slaves! [02:45:22] <ramiro> oops, distcc [02:45:29] <mru> funny, building firefox killed my laptop too once [02:45:50] <hyc> hm, I build seamonkey with no trouble on a laptop with 2GB [02:45:52] <Kovensky> ramiro: would distcc save ram? =p [02:46:11] <mru> it would build on another machine, presumably with more ram [02:46:16] <Kovensky> the box where I tried to compile firefox has 1.3G RAM, but runs ZFS, so ~ 300MB go to the ARC [02:46:42] <mru> my i7/12G has no problem building it in tmpfs [02:46:57] <Kovensky> oh you [02:47:23] <Compn> those intel i7 commercials are annoying [02:47:31] <mru> haven't seen them [02:47:33] <Compn> 'it speeds up your computer as you work' [02:47:34] <Dark_Shikari> well they are good chips. [02:47:39] * mru doesn't watch commercials [02:47:50] <hyc> it's probably time to start over from scratch. a new libc with no runtime patches for C++ support [02:47:53] <Compn> it just sounds so hokey [02:48:04] <hyc> and a new set of compiler/assembler/linker tools [02:48:07] <Dark_Shikari> mru: http://images.anandtech.com/graphs/amdphenomiix6_042610231918/22621.png [02:48:18] <Kovensky> the intel commercial here has a guy at some kind of cafeteria yelling that intel's chips are the best, that there's no room for competition, that it just destroys everyone else without a doubt, etc, etc, etc, and then shows a sad robot that overhead the ordeal [02:48:20] <Dark_Shikari> aka "hooooly fuck the 980X is o.0" [02:48:24] <Compn> hyc : dalias started working on his own uclibc thing, its in mplayer repo somewheres [02:48:26] <Kovensky> very annoying and not a good commercial at all [02:48:43] <hyc> I could just resurrect the C library we wrote for the Atari ST [02:48:48] <mru> what's magic in the 980X? [02:48:50] <Compn> hyc : and there is tinycc aka tcc created by fabrice [02:48:54] <Dark_Shikari> mru: two more cores [02:48:59] * mru has only a meagre 940 [02:49:01] <saintdev> i can has 12 threads [02:49:04] <mru> oh, that explains it [02:49:13] <hyc> I think I looked at tinycc, but it's x86 only [02:49:22] <Dark_Shikari> it's almost exaclty 50% faster [02:49:23] * Kovensky only has a meager T2370 and a Sempron2800+ [02:49:31] <mru> tinycc is a toy compiler [02:49:44] * Kovensky wonders why not clang, other than "eew C++" [02:50:00] <hyc> that's enough reason [02:50:05] <mru> I'm curious to see what happens with pathscale [02:50:08] <mru> probably also c++ [02:50:12] <Kovensky> lol [02:50:35] <hyc> I think the llvm project has some interesting ideas, but they're missing the most obvious [02:50:38] <Kovensky> what about pcc, that openbsd likes for wtf knows why [02:50:43] <mru> what's the difference between i5 and i7 anyway? [02:50:49] <Kovensky> s/wtf/only de rant/ [02:50:59] <Kovensky> hyc: which is? [02:51:12] <mru> make something that works [02:51:14] <hyc> llvm should be focusing on cross-compiling binaries [02:51:21] <ohsix> hyc: its more than x86 now, has been for ages [02:51:29] <hyc> bidirectional LVM - machine translation [02:51:37] <mru> not interesting [02:51:42] <mru> certainly not for open source [02:51:47] <hyc> right now they only go from bytecode to machine. go from machine back to bytecode. [02:52:00] <hyc> and then you can retarget any application to any hardware. [02:52:09] <hyc> just need to wrap the right runtime library around it. [02:52:20] <Compn> sounds like java :P [02:52:26] <mru> you'd always lose something in the conversion [02:52:42] <mru> the llvm bytecode is still more expressive than machine code [02:52:50] <hyc> mru: not enough to matter [02:53:16] <hyc> I was running MSDOS binaries translated to 68000 on my Atari ST back in 1986 [02:53:20] <mru> well, compilers suck badly enough at compiling C code with all manner of hints [02:53:29] <mru> that was a different world [02:53:40] <hyc> my first few were hand-translated, but I got it automated pretty smoothly [02:53:52] <mru> it's relatively easy to emulate x86 on 68k [02:54:07] <mru> or translate for that matter [02:54:09] <hyc> yes, that was a different world where self-modifying code was still pretty common [02:54:21] <hyc> today mosst object code is a lot more well-behaved [02:54:25] <mru> you have more registers, and the instruction set has a direct equivalent for most things [02:54:32] * Kovensky points at the senseless copy protections everywhere [02:54:49] <hyc> because CPU's have separate I$ and D$ and can't cope with writes to the instruction stream [02:54:53] <mru> the biggest catch might be the separate data and addres registers [02:55:19] <Kovensky> link not related: http://insomnia.ac/commentary/pc_game_piracy/ [02:55:19] <mru> hyc: it can be done, but you need to invalidate the I$ somehow [02:55:32] * Kovensky sleeps [02:55:39] <hyc> sure, but that is an obvious explicit instruction [02:55:57] <hyc> you can bring all of this up to the bytecode level [02:57:26] <hyc> it's not like the old days where you had to know the hardware memory map, because code was routinely peeking/poking dedicated I/O registers [02:58:00] <hyc> user-level apps on an OS with VM and memory protection - they have no choice but to be well-bheaved [02:58:06] <hyc> behaved [02:58:22] <ohsix> behooved, betrothed [03:01:10] <hyc> and you don't have to only do static analysis [03:01:59] <hyc> you have a VM.... you can use an approach like valgrind and actually trace the execution path of the machine code, when turning it into the bytecode [03:03:48] <peloverde> what about libraries? [03:05:03] <hyc> what about them? [03:07:22] <peloverde> well if you are retargeting some useful app from win/x86 to arm/linux you are going to have to suck in half of the win32 api [03:07:50] <hyc> hasn't wine already done that? [03:08:03] <hyc> so all you need is to retarget the wine librarys from x86 to arm [03:08:20] <peloverde> wine has huge swaths of missing features [03:08:34] <mru> usually the ones you need [03:08:40] <peloverde> indeed [03:08:43] <hyc> sure, but it also already has a large base of apps that work [03:08:51] <hyc> or people wouldn't bother with it [03:09:32] <hyc> regardless of whether wine is complete or not, it has > 0 functionality. [03:09:45] <mru> I guess those people run entirely different apps than the ones I've tried [03:09:47] <hyc> so if you absolutely wanted to get a win/x86 app to arm/linux [03:10:12] <hyc> it would be better to start by converting wine to arm, than to start from scratch [03:11:14] <peloverde> It might be better just to reimplement the app or reverse engineer the missing functionality than to retarget the binary [03:11:15] <ohsix> sounds like a job for qemu [03:11:39] <peloverde> or run it on an emulator [03:11:41] <hyc> qemumight work, but it would always be the slowest [03:12:03] <hyc> binary recompilation/translation would get you native execution speed [03:12:12] <mru> that's what I doubt [03:12:21] <hyc> and yes, just recompiling the app would be ideal. [03:12:24] <peloverde> reverse engineering can get you even bigger improvements [03:12:26] <ohsix> tcg, translating the whole thing still wouldn't get you the best you could get [03:12:32] <peloverde> look at the codecs FFmpeg has reversed [03:12:38] <hyc> but there may be some apps that you can't get the source code for any more, perhaps it's lost. [03:13:07] <peloverde> hexrays [03:13:56] <hyc> don't be silly. if youdon't think you can reliably convert machine code to usable bytecode, what makes you think you can fully decompile it all the way back to C source? [03:14:03] <mru> hyc: didn't stop us implementing RVxx, VP[56], indeo, wma, etc [03:14:21] <peloverde> Because the C code gets fixed up by a human being [03:14:21] <mru> hyc: I don't think a machine can do that either [03:14:26] <hyc> mru: sure, at significant labor cost. [03:14:29] <ohsix> hexrays is just for rapid comprehension [03:14:33] <mru> machines can't even compile C to asm [03:15:01] <hyc> I think, you spend the labor on the machine code to bytecode framework, and then you don't have to sweat any more. [03:15:52] <ohsix> the problem is universal representation and a form that covers its manipulation in a useful manne [03:15:55] <ohsix> r [03:16:06] <mru> I think reverse engineering everything is less effort than making such a thing work [03:16:18] <peloverde> mru, agreed [03:16:48] <hyc> ohsix: if you believe that's a problem, then you must also believe that LLVM and JVM are inherently failures [03:17:03] <mru> jvm is a failure [03:17:06] <ohsix> heh [03:17:08] <mru> most people agree on that [03:17:12] <hyc> can't disagree with that ;) [03:17:53] <mru> the problem is that compiled code has less information than source code [03:18:18] <mru> for instance, if you see a load instruction on x86, you can't know anything about its alignment [03:18:18] <hyc> then you must also believe that gcc is inherently doomed, because it is a single frontend for multiple backends [03:18:44] <mru> the gcc frontends parse code into a high-level language-neutral representation [03:19:07] <ohsix> translation from a higher level to a lower level can freely discard semantics from the constraints of the higher level [03:19:15] <hyc> how is high-level language-neutral rep in any way different from bytecode? [03:19:25] <hyc> the old gcc used RTL [03:19:31] <mru> gcc still uses rtl [03:19:36] <hyc> there were no source-level semantics preserved in RTL [03:19:48] <mru> things like alignment constraints are preserved [03:20:42] <mru> I don't know llvm bytecode, but it could easily preserve more than any specific machine code [03:21:07] <mru> like separating aligned and unaligned loads [03:21:42] <Yuvi> yeah, it keeps alignment [03:22:19] <mru> it could also include non-code annotations [03:22:44] <hyc> so worst-case you get some performance hits because you have to turn some unaligned word-sized loads into byte ops [03:22:58] <mru> that was just one example [03:23:07] <hyc> yes [03:23:19] <hyc> I'm sure there are other problems, and each of them can be solved [03:23:50] <mru> that's what I don't think [03:23:57] <peloverde> what would you do about unions where types can change size based on architecture and union punning is used? [03:24:09] <ohsix> but theres no universal way to discover semantics from a bit of code, even when not in isolation [03:24:15] <mru> not until I can have a crystal ball with pci interface [03:24:31] <ohsix> takes people and inferences, theories being disproven to really hone in on it [03:25:16] <hyc> peloverde: re: unions, type sizes - you use bytes. [03:25:21] <ohsix> which is not an unreasonable way to resolve some of the stickier problems, but then you have an open set of solvers to run on something that still would miss things [03:25:35] <hyc> how did people do less-than-64-bit ops on Alpha... [03:25:48] <mru> load modify store [03:25:58] <peloverde> but address sizes change [03:25:58] <mru> sometimes with sparse mappings [03:26:12] <mru> in the end, it all boils down to the halting problem [03:26:20] <mru> and we know that's impossible to solve [03:26:29] <peloverde> or would your 32-bit program still be limited to 4GB? [03:27:03] <hyc> sure, that would be OK as a first effort [03:27:18] <hyc> and not an issue for this example, x86 to arm [03:28:00] <mru> a lot of apps nowadays are for x86_64 [03:28:02] <hyc> "impossible to solve" == no algorithm. but heuristics are ok. [03:28:09] <hyc> not on windows [03:28:37] <mru> look, after a decade of work, wine is still nowhere near ready [03:28:39] <hyc> you don't need a mathematical proof that it will be 100% correct [03:28:46] <mru> and that's emulating windows on its native platform [03:28:51] <hyc> you only need it to come close [03:28:57] <hyc> and wine is a poor example [03:29:03] <mru> emulating windows on _another_ architecture isn't going to be easy [03:29:17] <ohsix> who will be bodging over the failures though; you cant run every program ever and you eventually want someone to use it, no? [03:29:25] <hyc> I used to work at Locus Computing, andwe had PC-Merge back then running full Windows concurrent with Unix [03:29:50] <hyc> wine's lack of progress is no indication of the scope of the task. it's been done before, well. [03:30:08] <mru> one problem is that the scope is growing [03:30:24] <mru> 15 years ago win32 was much simpler [03:30:41] <mru> and apps were simpler too [03:31:38] <hyc> I suppose [03:32:33] <ohsix> every new release of windows ends up with new coverage and facilities over bits something like wine still has to maintain; but never got very far with in the first place [03:34:11] <hyc> and if you had machine-level translation, all of that maiintenance/verification would go a lot faster [03:34:38] <hyc> CPus are faster, mmemory sizes are larger, overall system complexit increases. fine. [03:35:01] <hyc> that justmakes it all the more clear that you should be using machine resources for these jobs, not brainpower [03:35:58] <hyc> the scope of the problem is not unbounded. it is completely contained in a PC. it is completely contained in a Vmware or virtualbox instance. [03:36:57] <ohsix> they just do a decent job bodging over the unvirtualizable bits and the rest is mostly orthogonal [03:37:39] <peloverde> VMWare solves a simpler problem slower [03:37:52] <hyc> the point remains - the problem is probably beyond the scope that any human programmer wants to address directly [03:38:09] <hyc> but it is not beyond the scope of a too [03:38:10] <hyc> tool [03:38:13] <mru> and the problem of automating it well is probably bigger [03:38:33] <peloverde> but people right here solve that problem all the time voluntarily [03:39:13] <peloverde> (not the problem of automating it, the problem of translating it) [03:39:41] <ohsix> automation would be for the bodges and stuff where it just falls flat [03:39:46] <hyc> yes, but as you pointed out, translating for wine is still incomplete. and yet complete PC virtual environments are commonplace. [03:40:16] <mru> hardware virtualisation is "trivial" [03:40:29] <ohsix> ^ [03:40:32] <hyc> or qemu, emulating the complete system on a foreign architecture [03:40:34] <mru> certainly on modern hardware [03:40:39] <mru> and on old big iron [03:41:02] <hyc> qemu works, but it's too slow [03:41:04] <ohsix> raw x86 only has a few problematic and old instructions that you just need to scan for [03:41:21] <mru> hw virt isn't conceptually quite similar to multi-processing with virtual memory [03:41:27] <mru> you just have one more level [03:42:07] <hyc> hw virt isn't what I'm talking about... full system emulation. [03:42:11] <mru> qemu translates one basic block at a time to native machine code and caches them [03:42:16] <hyc> like running virtualPC on 68K or sparc [03:42:35] <mru> that's also a trivial task [03:42:56] <mru> trivial to do correctly, hard to do fast [03:43:13] <mru> which is why we compile to native machine code when possible [03:43:16] <hyc> and?? you don't think you can analyze an arbitrary piece of machine code, one basic nlock at a time? [03:43:22] <hyc> block [03:43:45] <mru> and expect to recover all the information available at source level, no [03:43:52] <hyc> nobody cares about that [03:43:55] <mru> I do [03:44:06] <hyc> you just need to turn it into an executable stream for the current machine [03:44:08] <mru> and I suspect most of the others here too [03:44:16] <mru> it'll be a slow one [03:45:03] <hyc> there's no reason for that. [03:45:19] <mru> yes there is, and I just told you what it is [03:45:22] <hyc> you can do all the usual data flow analysis of a good compiler/optimizer [03:45:25] <mru> no [03:45:32] <mru> you're missing essential information [03:45:40] <mru> such as source-level types [03:46:08] <hyc> types are for humans. computers don't care. [03:46:12] <mru> oh yes they do [03:46:15] <ohsix> wat you do is turn them all into loops and do mathematical transformations on them!11 [03:46:37] <mru> what did you think all the strict aliasing was about? [03:46:42] <mru> and pointer alignment [03:46:57] <mru> and const declarations [03:47:03] <hyc> strict aliasing == nonsense. couldn't stand that crap. [03:47:12] <mru> that's your personal opinion [03:47:20] <mru> don't let that get in the way of facts [03:47:21] <hyc> const - is embedded in the binary already [03:47:35] <hyc> because consts will be in a different segment from writable data [03:48:15] <mru> void foo(const int *x) { do stuff with x; } [03:48:17] <hyc> pointer alignment - is embodied in the instructions that operate on a pointer [03:48:24] <mru> not on x86 and ppc [03:48:48] <mru> in a function like above, when compiled there's no way of knowing the pointer target is const [03:48:59] <hyc> nor is there any need to know [03:49:07] <mru> might be [03:49:18] <hyc> the object code will either atteempt to write thru it or not. [03:49:32] <hyc> if the compiler did its job correctly, the object code will be consistent [03:49:53] <mru> well, what are you waiting for? [03:50:07] <mru> write that perfect decompiler, translator, or whatever you want to call it [03:50:19] <mru> do what nobody has managed to do for 40 years of computing [03:50:28] <mru> or however long they've been trying [03:50:35] <hyc> how many have actually tried? [03:50:52] <hyc> it's been mostly ignored [03:50:55] <mru> only a bunch of phd studends per year per university [03:51:26] <hyc> oh well, that's their problem [03:51:35] <mru> you're not making a lot of sense [03:51:49] <mru> either you do it, or you shut up [03:52:03] <hyc> I already did an x86 to 68k translator [03:52:10] <hyc> it's on the Atari software archives [03:52:18] <mru> oooooh, impressive [03:52:38] <mru> and how good was it? [03:52:52] <mru> as I said, doing it at all isn't the hard part [03:53:03] <mru> it's doing it well that's close to impossible [03:53:13] <hyc> it worked for the apps I was interested in. MS Word 1.something, fractint [03:53:28] <mru> now you're talking about correctness [03:53:34] <mru> how fast was the result? [03:53:35] <hyc> you have to start somewhere [03:53:57] <mru> dammit, do you know how much people pay me to convert C code into assembler? [03:54:16] <hyc> nope. why should that concern me? [03:54:30] <hyc> you know how many years I worked on gcc for free? [03:54:38] <hyc> 68K and i860 [03:54:53] <peloverde> because converting assembler to assembler is significantly more difficult [03:55:26] <mru> one week of my money would buy a very good compiler [03:55:35] <mru> but they still think I'm worth it [03:55:48] <hyc> I also routinely ported assembly code between my 68K at home and the IBM 370 mainframe at the computing center [03:56:07] <hyc> you make it sound like it's impossible. it's not. [03:56:27] <mru> it's impossible to recover lost information [03:56:36] <hyc> true [03:56:38] <mru> and the process of compiling source code loses information [03:56:49] <hyc> but the lost information isn't always necessary [03:57:02] <mru> maybe not all of it [03:57:09] <mru> but enough of it is [03:57:30] <mru> another example: volatile [03:57:51] <mru> you can't tell from the asm whether something was declared volatile or the compiler just had to spill a register [03:58:15] <ohsix> or it really likes reading the contents of something [03:58:20] <hyc> lol [03:58:26] <mru> yeah, or it simply sucks [03:58:42] <mru> gcc does that a lot [03:58:45] <ohsix> yea, cant rule that out either [03:58:49] <mru> if you worked on it you should know [03:58:58] <hyc> true. but the latter case (reading the contents of something) is pretty rare. e.g. hardware register accesses [03:59:10] <mru> but you can't know for sure [03:59:11] <ohsix> needless loads in some of the passes cant be removed simply because the semantics have already been discarded, so it has to leave the loads in [03:59:29] <hyc> right [04:00:01] <mru> so moving from a register-starved machine to one with more registers, you'll probably be forced to do some redundant memory accesses [04:00:02] <hyc> but that's ok. your aim is to duplicate the behavior of the original code. [04:00:13] <peloverde> that still seems faster than emulating, presumably this is a somewhat lossy process speedwise, just less lossy than emulation [04:00:17] <mru> and if the source allows unaligned accesses, but not the target, well... [04:00:26] <ohsix> but faster enough than emulation to warrant the exercise [04:00:44] <mru> I never considered emulation as an alternative [04:00:59] <hyc> no, emulation kinda sucks. [04:01:05] <peloverde> emulation is the next best alternative is it not? [04:01:08] <hyc> but a lot of people use it if they have no better choice [04:01:08] <ohsix> drc can be pretty fast [04:01:18] <hyc> I think this is a better choice than emulation. [04:01:33] <mru> when is recompiling from source not an option? [04:01:40] <peloverde> yes [04:01:57] <peloverde> if recompiling from source were an option you'd just do that [04:02:02] <hyc> well in my case, I didn't have the source code to MSWord 1.0 [04:02:17] <mru> that's atypical [04:02:35] <ohsix> probably not a lot of volatile or type punning going on there either [04:03:09] <mru> and good luck doing anything sensible with simd [04:03:37] <mru> for example, sse and neon implementations often look very different [04:04:08] <peloverde> presumably generating scalar code or shittier simd on the target is an option [04:04:18] <peloverde> because it is till faster than emulation [04:04:26] <mru> you'd have to decompose the instructions into scalar operations, reconstruct the high-level loops, transform those into something efficient for the target insn set, and then compile them [04:04:36] <mru> modern compilers suck horribly at the easy parts there [04:04:39] <ohsix> basically all you're left with for semantics is the actual instructions you'd want to transform, and if you mess with those you have a malfunctioning program [04:05:13] <mru> your flaw is comparing to emulation [04:05:27] <peloverde> what is you next best alternative then? [04:05:29] <mru> you should be comparing to the best feasible option, not the worst [04:05:43] <hyc> the best feasible option is recompiling the source [04:05:44] <ohsix> broken in untestable or verifiable ways [04:06:00] <hyc> but you wouldn't even be looking down this path if that were an option [04:06:07] <peloverde> if you had the source why would you compile to x86 then retarget to ARM? [04:06:11] <mru> but it is almost always an option [04:06:16] <hyc> and in my case, that wasn't an option [04:06:32] <mru> guess what, it's not 1983 anymore [04:06:33] <hyc> and you'll find a lot of enterprises with legacy apps that never had source code available [04:06:39] <hyc> sold by vendors who are long out of business [04:06:46] <mru> they keep the old hardware available too [04:07:01] <hyc> for as long as they can, sure [04:07:01] <ohsix> msword 1.0 is probably fully comprehendable from the byte code :O [04:07:09] <peloverde> if it's legacy emulation should be fast enough [04:07:17] <mru> that too [04:07:21] <hyc> but old hardware has stiff maintenance costs, and probably is nowhere near power efficient [04:07:36] <mru> some companies are willing to pay for it [04:07:52] <mru> some old vax parts can fetch a good price [04:08:36] <hyc> peloverde: why settle for "good enough", particularly when emulation will consume far more CPU resources than otherwise [04:08:54] <mru> emulation is much less error-prone [04:09:04] <mru> presumably these legacy apps are very important [04:09:07] <peloverde> because good enough is availible right now [04:09:08] <hyc> just because I buy a new machine whose CPU can emulate the legacy system at 2x speed, why would I, if it means running 100% utilization [04:09:12] <mru> you won't want them to malfunction [04:09:49] <hyc> I'd rather be running at 10x speed and 1% CPU utilization... [04:10:12] <peloverde> If your MS-DOS business app from 1983 ran fine on a 286 it will work plenty fin on an emulator on an i7 [04:10:35] <hyc> and as you guys have pointed out, probably those legacy apps don't have any complexities to be translated [04:10:39] <mru> or anything else built in the last 10 years [04:11:02] <mru> you're building a spaceship to drive around the block in [04:11:06] <mru> there's just no point [04:11:16] <peloverde> and you don't have to hire a single person to write this elaborate system [04:12:04] <hyc> mru: I'm surprised to hear you say that. you seem to spend hours to shave 10% off a codec's runtime. [04:12:22] <ohsix> that's nothing like the same thing [04:12:23] <peloverde> "spaceship to drive around the block" perfect metaphor [04:12:43] <ohsix> and those changes have multiple consumers and for the scope of the project do much more than that 10% [04:13:14] <mru> hyc: and you're willing to spend months or years to _add_ 10% to the runtime [04:14:22] <hyc> I believe the end result will be a net-win in time saved. [04:14:46] <mru> I don't [04:15:07] <ohsix> it would have limited motility too [04:15:29] <peloverde> I think if it were a net win, you'd see it being done just like emulators and visualization [04:15:44] <mru> s/vis/virt/ ? [04:15:53] <peloverde> yes [04:16:12] <mru> actually, machine translators have been made [04:16:18] <mru> there was fx32 for alpha [04:16:24] <peloverde> apparently my spellcheck doesn't like "virtualization" [04:16:26] <mru> translated x86 code to alpha [04:16:31] <hyc> yes, which ran faster than real x86 [04:16:46] <mru> on hardware that was twice as fast to begin with [04:17:03] <mru> and again, translating from x86 to alpha is fairly easy [04:17:10] <mru> alpha has 32 registers [04:17:11] <hyc> still, it was better than emulation [04:17:23] <mru> you can just reserve 8 of those for the translated ones [04:18:04] <peloverde> It only worked for a very small niche [04:18:18] <ohsix> and when it didn't work, it was transparent to the user [04:19:04] <peloverde> The programs had to run on the same, specific, OS it had one source architecture and one target architecture and the target architecture had more registers [04:19:42] <peloverde> And despite it's existence NT on alpha was a flop [04:19:55] <hyc> well, x86 to *anything* will probably have more registers available [04:24:22] <peloverde> It wouldn't surprise me if something pops up to go from Windows on x86 to Windows on ARM or Mac OS X on x86 to OS X on ARM, but I wouldn't want to run Windows or OS X as a target OS [04:24:38] <mru> windows on arm, lol [04:24:54] <mru> that is so going to die [04:25:58] <hyc> full windows, or winmo7? [04:26:22] <mru> there has never been a full windows for arm [04:26:25] <peloverde> i'm sure full windows on ARM exists somewhere inside MS [04:26:57] <ohsix> eh @ that [04:27:34] <mru> winmo is totally lagging behind hw development [04:27:36] <hyc> kinda wonder. does M$ have any reason to stay on x86? [04:27:40] <mru> and I don't see many new devices coming out [04:27:55] <mru> windows is probably a bitch to port [04:28:02] <peloverde> the main reason to use windows is the huge binary only software library [04:28:16] <hyc> yes, which comes back to ... translation ... [04:28:23] <mru> nobody uses windows for the features alone [04:28:25] <hyc> they've already ported windows to MIPS and itanium [04:28:39] <mru> but we don't know how much effort that was [04:28:48] <mru> nor how well it worked [04:28:59] <mru> nor if those ports are still up to date [04:29:07] <peloverde> It's *supposedly* trivial [04:29:17] <hyc> hm, there are windows server deployments on itanium, so some folks must think it works ok [04:29:18] <peloverde> Isn't Windows on Itanium still supported [04:29:45] <hyc> it's been end-of-life'd [04:29:48] <mru> itanium isn't supported for much longer [04:29:50] <mru> if at all [04:29:53] <mru> by intel [04:30:15] <mru> the original one [04:30:28] <peloverde> Windows Server 2008 R2 stil supports itanium [04:30:41] <peloverde> that is their newest server OS [04:31:39] <ohsix> porting isn't 0 effort, its not hard since NT's inception; its just pretty useless [04:31:43] <hyc> yes. pretty sure that is the final update [04:32:39] <peloverde> anyway the problem with a windows port is most software is binary only [04:33:09] <peloverde> so it's only really used when their is also a paradigm shift like embedded or game console [04:33:12] <hyc> http://blogs.technet.com/windowsserver/archive/2010/04/02/windows-server-20… [04:34:43] <hyc> so anyway, no, I wouldn't invest any time in a binary translator for x86 to itanium... [04:35:08] <hyc> nor x86 to sparc [04:37:29] <peloverde> I wouldn't invest any time in either of those either [04:38:34] <peloverde> but i'd go further and say I wouldn't bother investing an time in any binary translator because the binary-only programs I care about don't run well in wine [04:39:20] <hyc> that sounded like a non-sequitur [04:39:38] <hyc> but what apps do you care about? [04:40:46] <peloverde> MS Word, Excel, to a lesser extent MATLAB [04:40:51] <hyc> I have to admit, it's been a long time since I've needed a particular windows app [04:41:01] <mru> matlab? [04:41:06] <mru> that has linux builds [04:41:27] <peloverde> I said binary only not windows only [04:41:41] <superdump> morning [04:41:44] <mru> you mentioned wine [04:42:04] <hyc> yeah, that was the non-sequitur part [04:43:15] <peloverde> everything I use in linux except for a driver and a browser plugin I have source code for [04:43:16] <ohsix> theres some irony in bringing up itanium wjen you're talking about retargeting x86 code [04:43:50] <mru> doesn't it have hw emulator? [04:45:09] <ohsix> peloverde: which driver? [04:45:16] <peloverde> nvidia [04:45:32] <ohsix> ah, drag [04:46:18] <superdump> mru: you've been called a moron on slashdot [04:46:25] <peloverde> so I would rather have llvm be a good c/c++ compiler because most of the code I run is compiled c/c++ [04:46:36] <mru> superdump: I've been called a lot of things lately [04:46:48] <superdump> http://rss.slashdot.org/~r/Slashdot/slashdot/~3/UsKme8j8QdI/Ogg-Format-Accu… [04:47:38] <peloverde> it seemed to not be a refutation as much as a list of nitpicks and minor corrections disguised as a rebuttal [04:47:59] <verb3k> Where can I find gsoc projects accepted for 2010? The gsoc website doesn't list the projects in the org page [04:49:15] <peloverde> the response it got on proggit surprised me considering proggit seems to have microsoft's cock in it's collective mouth [04:53:03] <peloverde> slashdot doesn't seem to be drinking the coolaid for the most part in the comments [04:53:57] <mru> I only saw a few sensible comments there, and they were all marked troll [04:54:26] <peloverde> As per slashdot the top comment is a joke [04:54:44] <peloverde> The next one is anti-ogg [04:54:48] <mru> I don't mind jokes [04:55:16] <mru> ranking has changed since I looked a few hours ago [04:55:49] <peloverde> The third one is pro-ogg, 4 and 5 are anti [04:56:07] <peloverde> blol 6 thinks you are an mpeg astotrufer [04:56:16] <Dark_Shikari> lol [04:56:30] <mru> yeah, that was funny [04:56:53] <mru> I don't understand why monty keeps going on about nut though [04:56:58] <mru> I didn't mention it even once [04:57:16] <peloverde> because ogg is indefensible [04:57:23] <peloverde> the best he can do is tear down a straw man [04:58:16] <peloverde> sigh, why do i never have slashdot modpoints when I need them [05:00:07] <peloverde> oh well at least I get to tag some new foes [05:08:38] <peloverde> brand new foes: bit01 (644603), Jesus_666 (702802), DaMattster (977781), kiwieater (1799016) [05:11:51] <peloverde> mostly for missing the point completely (talking about how great vorbis is, how good enough theora is) or astroturfing allegations [05:14:18] <peloverde> The number of people that have an opinion on this matter but wind up talking about vorbis or theora in a non-container-interface capacity is mind boggling [05:14:51] <peloverde> It's like they don't bother to read anything but their religion compels them to weigh in anyway [05:15:40] <ohsix> for real [06:26:45] <av500> "...An index is only marginally useful in Ogg for the complexity added; it adds no new functionality and seldom improves performance noticeably. Why add extra complexity if it gets you nothing? ..." [06:26:47] <av500> wtf? [07:39:05] <KotH> bon giorno [07:43:05] <pengvado> first version of CABGT done [07:43:20] <Dark_Shikari> how does it perform? [07:43:26] <pengvado> it works, it compresses within 0.3% of CABRC, and in unit test it's 1.4x faster to decode [07:43:35] <pengvado> but when plugged into actual FFV1, it's slower [07:44:21] <pengvado> I suppose it could be cache misses from all those huffman tables... [07:45:31] <Dark_Shikari> use smaller tables? [07:45:34] <Dark_Shikari> how large do the tables end up? [07:45:48] <Dark_Shikari> that actually sounds like a serious practical problem with CABGT. [07:46:03] <Dark_Shikari> even if it saves a dozen clocks, that's one miss... [07:51:04] <benoit-> hi [07:52:32] <pengvado> total of 119 symbols in 8 huffman trees. which expands to 2048 LUT entries after flattening. [07:52:35] <pengvado> which could be 119*2+2048 bytes with a custom implementation, but is 2048*4 bytes with the standard get_vlc(). [07:52:49] <Dark_Shikari> hmm. that shouldn't be enough to cause massive increases in cache misses [07:56:56] <pengvado> http://akuvian.org/src/x264/cabgt.0.diff [07:57:21] <pengvado> (patch made from my ffv2 tree, so there might be some conflicts with mainline, but should be simple enough) [08:00:33] <Dark_Shikari> what's with the lfg random stuff? [08:00:46] <Dark_Shikari> also, er, wouldn't branch mispredictions be more of a worry than cache misses? [08:02:45] <Dark_Shikari> what's with bitswap_32? [08:02:54] <Dark_Shikari> oh. an actual bit swap [08:07:57] <pengvado> lfg random stuff is the unit test [08:09:37] <pengvado> you mean the branch around get_vlc2? [08:09:48] <pengvado> how is that different from the branch around refill in cabrc? [08:10:35] <pengvado> btw, there's several useless instructions in gcc's output, but I can't find any C that eliminates them, and I'm not ready for asm [08:10:53] <Dark_Shikari> well you should do some actual benching of cache misses/etc [08:10:56] <Dark_Shikari> to check that your theory is correct [08:51:42] <pengvado> cachegrind says [08:51:42] <pengvado> CABRC: instructions executed: 55,574,444,565. D refs: 20,276,925,172. L1D misses: 74,439,371. L2 misses: 18,129,485. [08:51:46] <pengvado> CABGT: instructions executed: 66,501,922,459. D refs: 18,054,494,330. L1D misses: 112,887,770. L2 misses: 18,380,171. [08:52:09] <ohsix> <3 [10:02:11] <lu_zero> yawn [10:02:13] <lu_zero> good morning [10:02:33] <kshishkov> it's good day but good morning to you [10:02:43] <lu_zero> =) [10:29:48] <Yuvi> Does mpeg-ts have patents? [10:30:21] <pross-au> That is an intractable question [10:30:42] <Yuvi> Does it have known patents? [10:34:16] <Yuvi> Guess so given a search... [10:35:23] <av500> hmm: Both the DAB royalty to Philips and the AAC royalty to Via Licensing apply to DMB. In addition there is licence fee applicable for MPEG Transport Stream (TS) used in DMB. [10:35:32] <av500> The $0.50 per-unit licence fee for the MPEG TS is payable to MPEG LA. [11:33:14] <BastyCDGS> a wonderful day to all... [11:33:19] <kshishkov> ok [11:33:46] <KotH> BastyCDGS: especially to kshishkov, isnt it? ;) [11:34:02] <BastyCDGS> oh what's with you, kishkov? [11:34:15] <kshishkov> KotH: you know, days are quite better here near Rhine [11:34:24] <BastyCDGS> and also a wonderful day to IFF decoder, I just fixed the bug that some IFF files decode wrong ;) [11:34:27] <KotH> kshishkov: hmm? rhine? [11:34:31] <KotH> kshishkov: did you move to germany? [11:34:35] <kshishkov> KotH: yes [11:34:43] <BastyCDGS> oh where in germany? [11:34:44] <elenril> permanently? [11:34:50] <kshishkov> hopefully [11:34:54] <elenril> \o/ [11:34:54] <KotH> \o/ [11:34:58] <elenril> lol [11:35:00] <kshishkov> BastyCDGS: Karlsruhe [11:35:10] <BastyCDGS> ahh nice [11:35:19] <KotH> oh.. that isnt that far [11:35:25] <BastyCDGS> that's pretty close where my family lives (Freiburg) [11:36:41] <iive> kshishkov: congratulations. [11:38:52] <BastyCDGS> YEAH! With new patch ALL remaining IFF decoding errors are resolved, just tried on all samples which decoded wrong before [11:38:55] <BastyCDGS> except HAM/EHB ;) [11:39:24] <kshishkov> you'd better test _all_ files anyway [11:39:36] * elenril thinks gluing fortran and c code together with python is fun [11:39:42] <BastyCDGS> I now create the heavy opt patches based on this [11:39:51] <BastyCDGS> and them I commit HAM ;) [11:39:57] <BastyCDGS> s/commit/submit [11:40:48] <mru> why would you need python for that? [11:41:00] <mru> fortran and c can be compiled and linked directly [11:41:16] <elenril> most of the code is python, it's easier that way [11:41:26] <elenril> only the ode solver is fortran [11:41:43] <elenril> and the ode system is in c [11:43:41] <merbzt> kshishkov: \o/ [12:11:40] <benoit-> kshishkov: congrats ! [12:20:41] <wbs> siretart: hey, regarding ffmpeg packaging for debian/ubuntu, what about packaging qt-faststart as a separate package? [12:24:44] <BastyCDGS> submitted heavy opt patch for dp8 based on IFF line rounding up to next word boundary to ml [12:26:19] <siretart> wbs: err, technically, this would be possible, but I don't really understand the merit for this. [12:26:53] <kshishkov> siretart: for really clueless users who don't associate it with FFmpeg, I presume [12:27:19] <wbs> siretart: in some cases, I bring my own libav* in my own app, but may want to simply apt-get in qt-faststart (without having a system-wide installed libav*) [12:27:21] <kshishkov> also it does not have any external dependencies [12:27:37] <merbzt> BastyCDGS: so just a 70% improvement :) [12:27:55] <BastyCDGS> 70%?? [12:27:59] <BastyCDGS> it's almost 400% [12:28:04] <siretart> wbs: a single utility binary package feel really too much overhead to me. perhaps we can include it in some other package? [12:28:18] <merbzt> er 30% of the previous time [12:28:23] <merbzt> good work [12:28:52] <BastyCDGS> 53429 vs 14492 [12:28:53] <BastyCDGS> ;) [12:28:58] <BastyCDGS> I used a larger file this time [12:28:59] <wbs> siretart: hmm, what other packages are built from the source package, libav* and the main ffmpeg package? [12:29:47] <siretart> wbs: http://packages.debian.org/sid/source/ffmpeg [12:30:16] <merbzt> BastyCDGS: did you update the Roundup tickets ? if the bugfix took care of them [12:30:51] <wbs> hmm, ok.. so if a separate package is too much overhead, I guess I can live with the current packaging [12:31:29] <siretart> wbs: there is an open request to seperate out ffplay to a package of it's own already, which I'm currently considering [12:31:39] <wbs> hmm, ok [12:31:51] <siretart> but I guess this wouldn't help you here very much [12:32:04] <wbs> the point in this case, from my part, is that qt-faststart wouldn't have any other deps than libc, more or less [12:32:09] <siretart> wbs: what's your usecase for not wanting to install any system libavcodec package? [12:32:58] <wbs> siretart: a custom app with a built-in static copy of lav* (pinned to the version I've tested it with), but i'd like to run qt-faststart using system() or something like that [12:33:52] <siretart> wbs: okay, but what's the problem with installing debian's libavcodec package? [12:34:09] <siretart> if you link statically, the system lib will be ignored [12:34:26] <BastyCDGS> merbzt, is it okay, when I do this when the patch has been commited to git? [12:34:48] <wbs> siretart: there's no concrete problem in doing that, it just feels unnecessary since qt-faststart doesn't need any of it [12:35:55] <siretart> wbs: well, let me put it this way: I certainly won't introduce new binary package if that doesn't solve any problems [12:36:31] <wbs> ok, then consider the feature request dropped :-) [12:36:35] <siretart> as for ffplay, seperating it out would allow users to avoid the SDL dependencies [12:36:50] <siretart> which can be considered as a problem in some cases [12:37:12] <mru> sdl is a problem, I'll agree to that [12:37:38] <siretart> ah, we've found a volunteer to port ffplay to libvo :-) [12:37:46] * mru prefers poking the hardware directly :-) [12:38:09] <av500> /dev/dsp and /dev/fb should be all you need [12:38:19] <av500> or /dev/mem actually [12:38:32] <kshishkov> mru: blame crappy X11 protocol implementations [12:38:44] <KotH> siretart: which libvo? [12:38:44] <mru> kshishkov: x11 is not to blame for sdl [12:38:55] <twnqx> av500: how would you get the interrupts back :X [12:39:08] <KotH> siretart: "the" libvo, mplayers libvo, xines libvo or vlcs libvo? [12:39:13] <kshishkov> KotH: our own libavoutput [12:39:22] <KotH> ah.. libavo [12:39:33] <mru> isn't that lavd? [12:39:34] <siretart> KotH: at the implementor's choice :-) [12:39:37] <KotH> .o0(wonders when a libova will be made) [12:39:43] <av500> twnqx: I dont want your interrupt back, you can keep it [12:39:48] <siretart> libass is a nice one [12:39:58] <kshishkov> KotH: ask that at #mplayerdev, they should know [12:40:29] <KotH> kshishkov: mplayers libvo is based on "the" libvo... or vice versa.. nobody knows anymore [12:40:44] <KotH> kshishkov: xine and vlc build their own [12:41:28] <KotH> siretart: only if it's a nice ass ;-) [12:41:30] <kshishkov> KotH: I meant your "libova" question, I know a bit about libmpeg2 vo [12:43:00] <merbzt> BastyCDGS: you can add a comment that a patch fixing this bug is posted on the mailinglist [12:43:36] <BastyCDGS> isn't that what I wrote already regarding this patch, enough? [12:44:36] <mru> http://blog.axant.it/archives/278 [12:44:51] <mru> whos blog is that? [12:45:16] <merbzt> BastyCDGS: you did ? then there is no need to do anythjing until the fix is committed [12:45:37] <BastyCDGS> that's what I wrote: [12:45:42] <BastyCDGS> I have fixed the wrong IFF decoding issue in the IFF decoder. [12:45:42] <BastyCDGS> The reason is that the IFF docs say that each line in the BODY chunk has [12:45:42] <BastyCDGS> it's width rounded up to next 16-bit boundary, such that each new line [12:45:42] <BastyCDGS> begins on a word boundary (address divisible by 2). [12:45:42] <BastyCDGS> Please review and apply. [12:45:43] <BastyCDGS> I will do the heavy optimization stuff now based on this. [12:46:18] <av500> mru: Barbato Luca [12:46:29] <av500> http://www.axant.it/legalinfo?lang=it [12:46:56] <mru> lu_zero: thanks [12:47:39] <av500> actually, the mention of feng should have given it away, no? :) [12:48:11] <mru> yeah, I guess [12:54:37] <ohsix> heh, that reads as "i dislike ogg and didn't read what was posted" [12:56:03] <av500> ohsix: not reading is a prerequisite for all succesful internet discussion :) [12:56:11] <ohsix> :] [12:56:33] <ohsix> doesn't have much weight though; and we know the internet is of finite size [13:03:14] <KotH> av500: "successful" is a very strong precondition ;) [13:06:11] <ohsix> trench warfare doesn't gain you any territory [13:09:07] <BastyCDGS> mru, I just tried your idea with decodeplane32 [13:09:21] <BastyCDGS> is twice as slow than my original heavy opt of dp32 [13:09:29] <mru> I don't believe you [13:09:37] <mru> I don't think your lying [13:09:43] <mru> but I think you made a mistake somewhere [13:09:56] <BastyCDGS> that's what I'm just figuring out right now [13:10:25] <BastyCDGS> I started with a table on stack pointing to the 4 masks [13:13:53] <BastyCDGS> declaring const uint32_t lut[4][16]; and memcpy from static table gives original speedup [13:14:56] <mru> don't memcpy [13:14:59] <mru> never, ever memcpy [13:15:06] <mru> what good could that possibly do [13:15:10] <BastyCDGS> yes I know was just as test ;) [13:15:18] <BastyCDGS> s/as/a [13:18:23] <BastyCDGS> hey BBB ;) [13:23:37] <BastyCDGS> mru, I dunno why, but the original method or memcpy is twice as fast than anything else I tried... [13:23:55] <BastyCDGS> should I submit a patch with current state and let someone look on it? [13:24:35] <BBB___> mornin' [13:24:59] <BBB___> I'd stop messing around with performance after your table-patch [13:25:01] <BBB___> work on iff/anim [13:25:07] <BastyCDGS> morning? it's 15:24 (GMT+02) here ;) [13:25:10] <BBB___> that was and is the qualification task :) [13:25:14] <BBB___> it's 9:25 here :) [13:25:24] <mru> BastyCDGS: if adding a memcpy makes it look faster you're doing something wrong [13:25:53] <jai> i second BBB :) [13:26:09] <BBB> the table patch is good and makes a huge difference [13:26:13] <BBB> that's good [13:26:29] <BastyCDGS> BBB, I dunno if you already realized but I fixed the bug displaying some IFF's wrong ;) [13:26:36] <jai> also if you _really_ want to optimize stuff/write asm, the h264 or vc1 decoders are much more useful targets [13:26:40] <BBB> I just reviewed that :) [13:28:24] <BastyCDGS> oh thanks, I just wrote * 2 because I'm afraid that mru then again complains about readability ;) [13:28:30] <av500> BastyCDGS: irc is on UGT timezone... [13:29:40] <BastyCDGS> BBB, the & 1 rounding will probably be slower (creates a larger instruction) than shl eax,1 [13:30:32] <mru> instruction prefetch on modern cpus is large enough the size of an single instruction rarely matters [13:34:35] <hyc> ? most Intels fetch 16 bytes at a time, new AMDs 32 bytes at a time [13:34:49] <BastyCDGS> mru, you're right, with & it shifts one bit less to right which is faster on some CPUs anyway [13:34:59] <BastyCDGS> so I will use the &~1 rounding ;) [13:35:07] <hyc> and the AMD optimization guide syas to avoid more than 2-3 branches per 16 bytes [13:35:25] <hyc> so instruction size/placement does need to be taken into consideration [13:35:59] <mru> hyc: 16 bytes is enough to hold several of the larger instructions [13:36:37] <mru> instruction size is only a problem if decode stalls waiting for fetch [13:36:47] <mru> or if the code size increases so much that you get I-cache misses [13:37:04] <mru> adding a byte to one instruction won't be noticed [13:37:12] <kshishkov> or it's German Instruction Word CPU [13:37:14] <BastyCDGS> well this code is called anyway only once (it's in decode_init), so that shouldn't be a problem ;) [13:37:45] <mru> init code is totally irrelevant [13:37:59] <hyc> typically true, yeah [13:38:19] <BastyCDGS> well unless I don't bloat it up from 16 bytes to 1 MB ;) [13:38:22] <hyc> (unless you're talking about libgcrypt, which does a full "self-test" when you initialize it. sigh.) [13:42:40] <hyc> this code reminds me of M68K, it was faster to add a number to itself than to do a 1 bit shift [13:43:06] <hyc> Then they added a barrel shifter in 68020 and idt didn't matter any more [13:45:13] <mru> and then there's the ARM [13:45:19] <mru> free shift with every instruction [13:45:24] <mru> (almost) [13:46:53] <BastyCDGS> hyc, on yes on m68k add.l dx,dx was 2 cycles faster than lsl.l #1,dx [13:47:08] <hyc> yep [13:47:16] <av500> can we try to make ffmpeg faster on existing cpus :) [13:47:29] <mru> and future ones [13:47:44] <hyc> sorry, I still fire up my 68030 Atari TT every once in a while to compile my code [13:47:48] <hyc> ;) [13:48:00] <kshishkov> FFmpeg? [13:48:06] <hyc> and apparently some Amiga folks are doing the same. rtmpdump [13:49:42] <hyc> If you guys need some nice and fast 68020 dsputil let me know, I've still got my fft libraries around here somewhere [13:50:07] <mru> they probably use a slow base algorithm [13:50:20] <mru> since the one we use in ffmpeg wasn't known when that code was likely written [13:50:50] <hyc> I wrote this at JPL back in 1992 [13:51:13] <mru> our fft algorithm is more recent [13:51:44] <hyc> hard to believe you could trim the ops down any further [13:52:06] <mru> well, djb did [13:52:16] <hyc> and most of my colleagues there had spent their lives doing signal processing [13:52:24] <hyc> I'll have to read up on it [13:52:26] <BastyCDGS> BBB, submitted new patch [13:52:28] <hyc> compare notes.. [13:53:46] <hyc> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-August/034193.html [13:53:51] <hyc> 2007? [13:54:27] <hyc> oh yeah, I also have a pretty good DSP56001 fixed point fft [13:54:36] <hyc> but now we're really reaching... [13:57:41] <BastyCDGS> BBB, the + bps - 1 stuff was there because the original code did divide by bps after it...rounding up [14:01:00] <merbzt> mru: we use a regular splitradix fft, although highly optimized [14:01:29] <merbzt> djb wrote a paper about the "tangent fft" [14:02:14] <BBB> BastyCDGS: I'm not quite sure what that means, but do it all separately [14:02:14] <merbzt> less mac's but the structure was harder to optimize [14:02:18] <BBB> don't do 10 things in a patch [14:02:19] <BBB> it's confusing [14:02:45] <BastyCDGS> I have shortened the new patch a lot, have you reviewed it? [14:02:52] <mru> merbzt: ok, I must have been confused by all the fft talk back when we replaced it [14:02:54] <BBB> not yet, I'm busy with some other stuff [14:03:00] <BBB> you don't want to know what I do for a living :) [14:03:23] <BastyCDGS> (including a mathematical proof that bps - 1 will cause buffer overflow error with new width code ;) [14:04:04] <merbzt> I think that for some platforms/cpu's a radix2 fft might be the fastest one [14:04:08] <BBB> I know it's a rounding up [14:04:17] <av500> BBB: you study bugs under a magnifiying glass? [14:04:18] <BBB> but I'm not convinced that you don't need the rounding anymore all of a sudden [14:04:25] <BBB> av500: mice, not bugs :) [14:04:42] <BBB> check http://ronald.bitfreak.net/publications.php and click the "article" links at the bottom [14:05:00] <BastyCDGS> BBB, just read the math proof [14:05:06] <BastyCDGS> that should clarify it [14:05:18] <BBB> why don't you need the roundup there anymore? [14:05:31] <BBB> I'll review later, need to do some real work also ;) [14:05:32] <BastyCDGS> because the old code didn't do it on decode_init and even this is wrong [14:05:46] <BBB> if it does it, it's probably fine [14:05:51] <BastyCDGS> the IFF specs say that each line of a BODY chunk MUST start on a word-boundary [14:05:54] <BBB> so give me a few hours and I'll commit if it's ok with me [14:05:58] <merbzt> hyc: if we get a fixed point fft, I guess that we'll reimport the one in Rockbox, it should be quite fast on current fixed point platforms [14:05:59] <mru> BBB: you slice and dice mice? [14:06:04] <BBB> mru: yes [14:06:12] <BBB> chop-chop-chop [14:06:26] <BastyCDGS> BBB, so you're stuck to keyboard only now? ;) [14:06:34] <kshishkov> mru: wanna mice and chips? [14:06:42] <hyc> optical, mechanical, or biological.... :P [14:06:46] <BastyCDGS> I just want the wire ;) [14:06:52] <kierank> plenty of mice at my local supermarket [14:07:03] <CIA-7> ffmpeg: stefano * r22972 /trunk/libavformat/file.c: [14:07:03] <CIA-7> ffmpeg: Make file_open() return the error code set in errno if open() fails, [14:07:03] <CIA-7> ffmpeg: rather than always ENOENT. [14:07:03] <CIA-7> ffmpeg: stefano * r22973 /trunk/ffmpeg.c: [14:07:04] <CIA-7> ffmpeg: Make ffmpeg use print_error() to make apparent the exact cause of [14:07:04] <CIA-7> ffmpeg: failure happened when trying to open the output file. [14:08:32] <CIA-7> ffmpeg: rbultje * r22974 /trunk/libavcodec/iff.c: (log message trimmed) [14:08:33] <CIA-7> ffmpeg: Switch some ints to unsigned (they can only have positive values, this allows [14:08:33] <CIA-7> ffmpeg: compiler to optimize some math from mul/div to shr/shl). Also add a cast to [14:08:33] <CIA-7> ffmpeg: uint32_t when calling decodeplane32(), this silences a compiler warning. [14:09:25] <av500> guys, are there patents behind .mp4 (as the container)? [14:09:32] <BBB> maybe [14:09:32] <av500> (known ones) [14:09:33] <CIA-7> ffmpeg: Lastly, in decodeplane8/32(), flatten a double-loop into a single-loop and [14:09:33] <CIA-7> ffmpeg: calculate the length once before entering the loop instead of during every [14:09:33] <CIA-7> ffmpeg: iteration (since it doesn't change). [14:09:33] <CIA-7> ffmpeg: rbultje * r22975 /trunk/libavcodec/iff.c: [14:09:34] <CIA-7> ffmpeg: Move some branches outside looped code. Should improve the generated asm (and [14:09:34] <CIA-7> ffmpeg: thus performance) slightly. [14:09:34] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs.basty googlemail com>. [14:09:35] <CIA-7> ffmpeg: rbultje * r22976 /trunk/libavcodec/iff.c: [14:09:35] <BBB> the spec says yes [14:09:36] <CIA-7> ffmpeg: Reidnent after r22795. [14:09:36] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs.basty googlemail com>. [14:09:43] <av500> it does? [14:10:34] <mru> there are known patents on bifs and hint tracks for streaming [14:10:40] <mru> neither of which are needed [14:11:20] <av500> ok [14:11:39] * BastyCDGS kicks these software patent guys into the sun [14:14:40] <BBB> hey cia is back alive :) [14:14:58] <BastyCDGS> BBB, just wondered because it took such long ;) [14:14:58] <jai> as in the intelligence agency? [14:15:03] <jai> oh ok [14:15:16] <jai> just realized the context [14:15:24] * jai kicks CIA-7 [14:15:26] <CIA-7> ow [14:15:44] <BastyCDGS> jai, if he would mean the other CIA, he wouldn't probably put a happy smile there ;) [14:16:03] <jai> :) [14:16:20] <BastyCDGS> but I'm still stuck with dp32 [14:16:25] <KotH> BastyCDGS: unless he works for them ;) [14:16:32] <BastyCDGS> still twice as slow :( [14:16:56] <BastyCDGS> I think dp32 is faster when using my original patch (I guess I run out of registers always here) [14:17:13] <BastyCDGS> also the realtime calculation is much less effort (the shift is only calculated once) [14:17:15] <av500> anybody has a copy of 14496-14 for me? [14:17:20] <BastyCDGS> the remaining are simply MOV's... [14:17:47] <BastyCDGS> mru, if you don't dare, I'ld like keep the original dp32 patch and just change it to reflect the new bug-fix patch [14:18:01] <wbs> av500: http://albin.abo.fi/~mstorsjo/c051533_ISO_IEC_14496-12_2008.pdf [14:18:25] <wbs> av500: got it somewhere publicly recently, but don't remember exactly where [14:18:32] <BBB> BastyCDGS: for optimization, learn to look at disassembly and "help" gcc [14:18:34] <mru> http://standards.iso.org/ittf/PubliclyAvailableStandards/ [14:18:38] <BBB> BastyCDGS: otherwise I have no good ideas :) [14:18:54] <BBB> I'll look later [14:18:54] <mru> hmm, that doesn't have -14 [14:18:56] <mru> only -12 [14:19:07] <mru> but -12 is the good one anyway [14:19:08] <wbs> ah, sorry, it was -12 that I had, too [14:19:10] <BastyCDGS> BBB, believe me I already did this and it puts a lot of shifts when using a static const [14:19:13] <mru> -14 is mostly useless [14:19:24] <BastyCDGS> in the inner loop [14:19:47] <BastyCDGS> thus there are more shifts in the inner loop with dp32-static patch than there are shifts in whole dp32 with dp32 original patch [14:20:11] <BastyCDGS> besides this dp32 non-static patch saves 6k bytes of memory [14:20:21] <av500> mru: ok, -12 I had :) [14:20:52] <BastyCDGS> mru, so please you would decide? [14:21:17] <BastyCDGS> BBB, you of course can also decide ;) [14:21:47] <av500> wbs: you have -14 too? [14:22:04] <BBB> BastyCDGS: need to review it [14:22:05] <wbs> av500: no, I think I got it from the url mru gave [14:22:17] <BBB> BastyCDGS: like dp8, mru and I came up with a better way [14:22:21] <BBB> BastyCDGS: might happen here also [14:22:29] <av500> ah [14:22:30] <BBB> BastyCDGS: so give us some time, optimization isn't an easy thing at times :) [14:22:44] <BBB> BastyCDGS: in the mean time, look at iff/anim [14:22:47] <BastyCDGS> with dp8 we solved that by killing one register, so there wasn't stack shuffle in the inner loop [14:22:55] <BastyCDGS> BBB, I want to do HAM/EHB first [14:22:57] <BBB> we might be able to do that for dp32 also [14:23:03] <BBB> ok, then do ham/ehb :) [14:23:06] <BBB> go go go :) [14:23:16] <BastyCDGS> libavcodec/iff.c is already ready for HAM ;) [14:24:13] <av500> wbs: but no -14 there :( [14:24:22] <BastyCDGS> sorry meant libavformat/iff.c [14:26:10] <BBB> so do libavcodec/iff.c ! :) [14:29:27] <BastyCDGS> just preparing dp32-patch [14:29:30] <BastyCDGS> then I go on ;) [14:29:51] <BastyCDGS> because that patch is unsastified anyway, I will keep the START/STOP_TIMER with the patch [14:29:58] <BastyCDGS> so I save you guys some typing time ;) [14:33:52] <BastyCDGS> dp32 patch submitted to ml [15:20:37] <BastyCDGS> one question, how gets the palette data in frame[1] gets created? [15:20:48] <kshishkov> by decoder [15:21:39] <BastyCDGS> no I mean the structure... [15:21:45] <kshishkov> you simply write 256 32-bit numbers containing R*65536+G*256+B [15:22:00] <BastyCDGS> the thing is set bps == 12 for indicate HAM6 and bps == 18 for indicate HAM8 [15:22:23] <BastyCDGS> kshishkov when I write to first element I get segfault [15:22:34] <kshishkov> check PIX_FMT_ [15:22:54] <BastyCDGS> is 24bpp but that's correct [15:23:07] <BastyCDGS> the thing that I need the color map for convert HAM6/8 image to 24bpp [15:23:30] <kshishkov> palette is available only for PIX_FMT_PAL9 [15:23:33] <kshishkov> *PAL8 [15:23:52] <BastyCDGS> oh then I have to use extradata stuff [15:24:11] <kshishkov> yes, that sounds more correct [15:27:52] <BastyCDGS> oh [15:28:03] <BastyCDGS> or is it legal to allocate a palette manually if 24bpp? [15:28:07] <BastyCDGS> that would be more easy [15:28:25] <BastyCDGS> and assign it to frame[1]? [15:28:43] <kshishkov> nope [15:29:01] <BastyCDGS> I'll need such a thing for EHB though [15:29:07] <kshishkov> allocate it in context if you want [15:29:20] <BastyCDGS> because the EHB palette is twice as large as normal palette [15:31:26] <BastyCDGS> oh got it [15:35:12] <BastyCDGS> does av_freep check if the pointer is NULL before freeing it? [15:35:21] <kshishkov> of course [15:39:35] <BastyCDGS> thanks...HAM6/8 decoding works...just colors are wrong ;) [15:39:44] <BastyCDGS> but that's because I didn't do the actual HAM decoding yet [15:39:52] <BastyCDGS> it justs decodes as normal 24bpp right now [15:39:58] <BastyCDGS> but window opens and is recognizeable ;) [15:44:22] <BastyCDGS> BBB, HAM6/8 decoding works almost perfectly [15:44:29] <BBB> that was quick [15:44:32] <BastyCDGS> just the actual decoding has to be done properly and it's finished [15:44:33] <BBB> ok, on to iff/anim :) [15:45:20] <mru> btw current svn gives different output for ooze on x86 and arm [15:45:30] <BBB> lol :) [15:45:49] <BastyCDGS> mru, is arm be? [15:45:53] <mru> no [15:46:01] <kshishkov> "maybe" [15:46:06] <mru> not the one I'm using [15:46:14] <kshishkov> IIRC, ARM and MIPS may be any endian [15:46:23] <mru> depends on the implementation [15:46:29] <BastyCDGS> mru, is 8pp decoded correctly? [15:46:35] <mru> armv7 doesn't support true BE anymore [15:46:46] <mru> heart is fine [15:47:06] <BastyCDGS> how does the output differ? [15:47:11] <BastyCDGS> could you supply a screenshot? [15:47:22] <mru> 8241de83c0ed5012eff486fca2e1d3f4 x86 [15:47:25] <mru> 9fc3fddd3ff59946fb3ab81e380385c5 arm [15:47:40] * mru watches it in md5 [15:47:49] <BastyCDGS> should I decode that image in my brain? :D [15:49:58] <kshishkov> no, you should verify your code [15:50:04] <BBB> mru: they're only ~8% different [15:50:09] <BBB> that's not so much [15:50:15] <BBB> pure randomness would be ~50% different [15:50:41] <mru> md5 doesn't work like that [15:50:43] <mru> and you know that [15:50:45] <BBB> duh :-p [15:50:56] <kshishkov> neither does Theory of Probability [15:50:59] <BBB> btw it's not his code, peter ross wrote this I think [15:51:00] <BastyCDGS> do you apply md5 on raw image output? [15:51:08] <mru> yes [15:51:12] <av500> not on the jpg? [15:51:16] <av500> :) [15:51:40] <BastyCDGS> do you see a difference in the actual image though? [15:51:49] <mru> didn't look [15:52:04] <av500> BastyCDGS: wrong approach [15:52:11] <BastyCDGS> what do you think is causing this? the actual code or gcc output? [15:52:21] <kshishkov> code [15:52:55] <BastyCDGS> mru, could you check if the original code before my patches does show the same behaviour? [15:54:40] <mru> a bunch of 00 bytes from x86 are ff from arm [15:55:09] <kshishkov> may be padding [15:56:35] <mru> the differences come in bursts of 6 bytes [15:56:39] <mru> 2664 bytes apart [15:56:48] <mru> that's 666*4 [15:56:56] <mru> width=666 [15:57:33] <kshishkov> devilous! [15:57:34] <mru> near the end of each line [15:57:46] <BBB> overreading? [15:57:48] <kshishkov> sounds like line end padding to me [15:57:50] <BBB> maybe his patch fixes it [15:57:57] <BBB> try that patch he posted [15:58:00] <kshishkov> BBB: no, may be not zeroing it [15:58:10] <BastyCDGS> as I said the old IFF decoding is wrong [15:58:15] <BBB> there's a memset(0) before each call to decodeplane8/32() [15:58:19] <BBB> so that's not it [15:58:25] <BBB> I think it's overreading of non-null data [15:58:56] <BastyCDGS> which image you're doing this? [15:59:03] <mru> ooze [16:00:01] <BastyCDGS> MRLake.iff showed white pixels (which would be the ff's) with the old code too where it shouldn't [16:00:53] <BastyCDGS> could you try ooze with my patch which also fixes MRLake.iff? [16:03:02] <BastyCDGS> BBB, regarding iff-anim, before I really continue this, all issues with IFF-ILBM itself should be solved [16:03:06] <av500> maybe there are some bad pixels oozing in? [16:03:11] <BastyCDGS> after HAM/EHB there's still missing: [16:03:14] <BastyCDGS> masking & transparent [16:03:19] <BastyCDGS> and maybe DPaint color cycling [16:03:45] <BastyCDGS> a image with mask isn't decoded properly now [16:04:00] <BastyCDGS> masking asks a extra bpp which has to be skipped completely (which the current code doesn't do) [16:04:07] <BastyCDGS> s/asks/adds [16:04:47] <BastyCDGS> masks are added by sprite editors on amiga which save IFF-ILBM [16:05:05] <BastyCDGS> masks allow the amiga hardware blitter to do extreme fast transparent drawing [16:05:17] <BastyCDGS> mask bpp = all other bpps ORed together [16:05:51] <BastyCDGS> thus in the mask bpp a bit is set when remaining planes have color index != 0 [16:23:07] <av500> mru: ...kill neon intrinsics, replace them by assembler in separate file to save kittens [16:23:42] <mru> who has neon intrinsics? [16:24:01] <av500> my coworker, until just now :) [16:24:07] <mru> commit message? [16:24:11] <av500> yup [16:24:17] <mru> :-) [16:24:26] <av500> seems he likes kittens [16:24:41] <mru> who doesn't? [16:24:51] <kshishkov> av500: then you know how to intimidate him next time [16:25:00] <kshishkov> mru: me [16:25:11] <mru> you're afraid of kittens? [16:25:23] <av500> kshishkov: I threatened him with killing kittens of course [16:25:25] <kshishkov> nope, I prefer cat way - I ignore them, they ignore me [16:26:02] <mru> cats are nice [16:26:35] <mru> then there's The Cat of course... [16:26:46] <mru> av500 knows what I'm talking about [16:26:47] <av500> speaking of which [16:26:54] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/CatsAreMean [16:27:24] <BastyCDGS> is such a thing ISO C? [16:27:27] <BastyCDGS> uint8_t ham_row[avctx->width]; [16:27:27] <kshishkov> "If cats looked like frogs we'd realize what nasty, cruel little bastards they are. Style. That's what people remember." [16:27:32] <BastyCDGS> gcc accepts it [16:27:36] <mru> BastyCDGS: don't do that [16:27:45] <mru> it's legal c99 but it's a bad idea [16:28:12] <BastyCDGS> I need a tmp buffer which does a decodeplane8 in a pal buffer [16:28:19] <mru> why? [16:28:20] <BastyCDGS> and then want to call decodeham on it [16:28:27] <BastyCDGS> it's the fastest way of decoding ham [16:28:50] <mru> I would have though a single pass would be faster [16:28:54] <mru> +t [16:28:54] * av500 prefers slicing ham [16:29:02] * kshishkov prefers skinka [16:29:07] <mru> same thing, no [16:29:47] <kshishkov> you can allocate it once in init time in context and reuse it for many times [16:29:53] <BastyCDGS> you have to decode all planes first before you can decode HAM itself [16:30:00] <BastyCDGS> per line [16:30:13] <mru> right [16:30:26] <mru> well, then av_malloc() a temp buffer and stick it in the context [16:30:33] <BastyCDGS> okay [16:30:38] <mru> never, ever use variable-length arrays [16:31:02] <av500> y? [16:31:08] <mru> they're evil [16:31:18] <av500> so is google but I use ot [16:31:19] <av500> izt [16:31:21] <av500> it [16:31:30] <av500> so why? [16:31:48] <mru> what happens if the size is absurdly large? [16:31:51] <kshishkov> well, VLA don't have any checks on their size IIRC [16:31:57] <mru> A: you blow the stack and die [16:32:01] <mru> if you're lucky [16:32:16] <kshishkov> and in any case you won't be handling error [16:32:19] <mru> also, some compilers simply call malloc() when they see a VLA [16:32:31] <mru> with no error checking, of course [16:32:35] <iive> also, valgrind can't detect out of memory access with them. [16:32:38] <mru> so if the malloc fails, you die [16:32:39] <BastyCDGS> ok nuff said ;) [16:33:09] <kierank> [17:32] <@mru> also, some compilers simply call malloc() when they see a VLA --> why's that? [16:33:16] <mru> furthermore, with gcc the function with the vla requires a frame pointer [16:33:20] <mru> -> eats one extra reg [16:33:32] <mru> and a function with a vla can't be inlined by gcc [16:33:39] <mru> for the same reason more or less [16:33:57] <mru> kierank: because they were written like that [16:35:02] <mru> av500: anyway, what of the cat? [16:35:36] <av500> I ask you, no? [16:35:51] <mru> 17:26 <+av500> speaking of which [16:36:10] <av500> speaking of which, what of the cat? [16:37:33] <mru> doing her thing I guess, as cats do [17:22:26] <BastyCDGS> BGRA means always that blue is at bits 24..31? [17:22:34] <BastyCDGS> and alpha at 0..7? [17:22:53] <BastyCDGS> PIX_FMT_BGR32 [17:22:56] <BastyCDGS> to be exact [18:28:34] <ramiro> anyone got "libavcodec.a(avpacket.o) has local relocation entries in non-writable section" linking lavc with the apple toolchain i686? (ffmpeg is configure with -mdynamic-no-pic) [18:30:40] <BastyCDGS> jai, I've a huge problem [18:31:04] <BastyCDGS> HAM decoder outputs garbarge [18:31:08] <jai> BastyCDGS: what would that be [18:31:16] <astrange> ramiro: are you building a shared library? [18:31:17] <BastyCDGS> avctx->bits_per_coded_sample must this be changed after decode_init from 12 and 18 to 24 [18:31:25] <BastyCDGS> ? [18:31:33] <BastyCDGS> I use 12 and 18 to indicate HAM streams [18:32:28] <ramiro> astrange: lav* are built as static libraries, but then they're linked together as a shared library (with some other stuff) [18:32:39] <astrange> use -Wl,-read_only_relocs,suppress [18:33:04] <jai> BastyCDGS: isnt that set in the demuxer? [18:33:05] <ramiro> in ffmpeg's extra ldflags or the dylib I'm building? [18:33:24] <BastyCDGS> yes it's set in the demuxer and evaluated in the decoder [18:33:38] <BastyCDGS> the decoder checks if bpp = 12 || bpp = 18 and calls HAM decoding stuff [18:33:41] <astrange> in the dylib link line [18:33:45] <BastyCDGS> it sets PIX_FMT_BGA32 [18:33:55] <BastyCDGS> but keeps bpp = 12 set [18:34:00] <BastyCDGS> resp. bpp = 18 [18:34:56] <jai> BastyCDGS: and the problem is? [18:35:18] <BastyCDGS> the output is complete garbarge and I'm pretty sure the ham decoder is correct according to specs (I even looked at disasm output) [18:35:36] <jai> BastyCDGS: pastebin your code [18:35:48] <jai> BastyCDGS: diff against lavc/iff.c would be fine [18:36:16] <BastyCDGS> here's a routine doing an unHAM: [18:36:19] <BastyCDGS> http://home.comcast.net/~erniew/lwsdk/sample/iff/load.c [18:36:26] <BastyCDGS> for comparision [18:38:10] <BastyCDGS> http://pastebin.org/190155 [18:43:06] <BastyCDGS> case 1 => modify blue, case 2 = modify red and case 3 = modify green in decodeham [18:44:54] <ramiro> astrange: thanks, that seems to have worked. now if I could just get libtool to create a .dylib instead of a .so... [18:50:47] <astrange> find the libtool target type that does -dynamiclib and not -bundle [18:51:07] <astrange> they're seperate types on mach-o but the same thing in elf [18:51:52] <jai> BastyCDGS: got a sample? [18:52:46] <BastyCDGS> jai: DCC? [18:52:51] <BastyCDGS> if yes, just accept [18:53:19] <jai> BastyCDGS: k [18:53:48] <BastyCDGS> waiting for accept ;) [18:55:18] <BastyCDGS> if it doesn't work (i.e. no receive window appears at you): [18:55:19] <BastyCDGS> http://roundup.ffmpeg.org/issue1727 [18:56:11] <jai> bleh, the port is blocked i guess [18:56:26] <jai> i'll grab the samples from roundup [18:57:01] <jai> BastyCDGS: "A1200Power.iff"? [18:57:26] <BastyCDGS> A400T_HAM6.IFF and A400T_HAM8.IFF [18:58:42] <ramiro> astrange: hm, sorry, I don't understand. [18:59:11] <_av500_> BastyCDGS: what alghorith is/was used to create ham images? [19:00:04] <jai> BastyCDGS: could you dcc the sample again [19:00:55] <BastyCDGS> dcc request sent [19:01:25] <jai> BastyCDGS: meh, still doesnt work [19:01:55] <jai> BastyCDGS: btw, which file on roundup? [19:03:45] <BastyCDGS> guess it's one of the rar files [19:04:04] <BastyCDGS> ilbm.rar [19:04:37] <jai> ok [19:07:28] <jai> BastyCDGS: also, are you NAT'd? [19:07:36] <BastyCDGS> yes [19:07:39] <jai> ah [19:07:41] <jai> that explains it [19:08:07] <jai> your client needs to use the router ip i guess [19:08:26] <jai> with the forwarding in place [19:09:07] * elenril wonders when will people start using ipv6 [19:09:35] <Dark_Shikari> never. [19:09:45] <jai> elenril: this is the third world, we dont have ipv6 [19:09:48] <elenril> evil lies [19:10:02] <elenril> jai: it's very hard to get ipv6 here too [19:10:13] <BastyCDGS> my ISP doesn't have native ipv6 too [19:10:16] <jai> BastyCDGS: basically, dcc_own_ip or whatever should be your router ip and dcc_port should be correctly forwarded [19:10:31] <jai> elenril: .cz? [19:10:34] <elenril> yes [19:10:38] <jai> ah [19:41:06] <BastyCDGS> jai [19:41:09] <BastyCDGS> I found it [19:41:27] <BastyCDGS> colors still wrong but at least I get a recognizable image ;) [19:41:31] <BastyCDGS> memset(s->ham_buf, 0, avctx->width); [19:41:53] <BastyCDGS> was before [19:41:54] <BastyCDGS> memset(row, 0, avctx->width << 2); [19:42:09] <BastyCDGS> since I was decoding into s->hambuf instead of row I had to clear that out instead lol [19:42:42] * BastyCDGS *bangshisheadonthewall* [20:01:17] <CIA-7> ffmpeg: stefano * r22972 /trunk/libavformat/file.c: [20:01:17] <CIA-7> ffmpeg: Make file_open() return the error code set in errno if open() fails, [20:01:17] <CIA-7> ffmpeg: rather than always ENOENT. [20:01:17] <CIA-7> ffmpeg: stefano * r22973 /trunk/ffmpeg.c: [20:01:18] <CIA-7> ffmpeg: Make ffmpeg use print_error() to make apparent the exact cause of [20:01:18] <CIA-7> ffmpeg: failure happened when trying to open the output file. [20:01:30] <CIA-7> ffmpeg: rbultje * r22974 /trunk/libavcodec/iff.c: (log message trimmed) [20:01:30] <CIA-7> ffmpeg: Switch some ints to unsigned (they can only have positive values, this allows [20:01:30] <CIA-7> ffmpeg: compiler to optimize some math from mul/div to shr/shl). Also add a cast to [20:01:30] <CIA-7> ffmpeg: uint32_t when calling decodeplane32(), this silences a compiler warning. [20:01:30] <CIA-7> ffmpeg: Lastly, in decodeplane8/32(), flatten a double-loop into a single-loop and [20:01:30] <CIA-7> ffmpeg: calculate the length once before entering the loop instead of during every [20:01:30] <CIA-7> ffmpeg: iteration (since it doesn't change). [20:01:31] <CIA-7> ffmpeg: rbultje * r22975 /trunk/libavcodec/iff.c: [20:01:48] <CIA-7> ffmpeg: Move some branches outside looped code. Should improve the generated asm (and [20:01:48] <CIA-7> ffmpeg: thus performance) slightly. [20:01:48] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs.basty googlemail com>. [20:01:48] <CIA-7> ffmpeg: rbultje * r22976 /trunk/libavcodec/iff.c: [20:01:48] <CIA-7> ffmpeg: Reidnent after r22795. [20:01:48] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs.basty googlemail com>. [20:01:49] <CIA-7> ffmpeg: rbultje * r22977 /trunk/libavformat/iff.c: [20:01:49] <CIA-7> ffmpeg: Make the IFF demuxer a little more standards-compliant, e.g. respect the size [20:01:50] <CIA-7> ffmpeg: fields of common media header chunks (these can have different sizes depending [20:01:50] <CIA-7> ffmpeg: on the type of IFF file you read), better handle odd sizes (like RIFF, every [20:01:51] <CIA-7> ffmpeg: field is padded to word) and handle headerchunks after the BODY chunk. [20:01:53] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs.basty googlemail com>. [20:01:53] <CIA-7> ffmpeg: rbultje * r22978 /trunk/libavformat/iff.c: [20:01:54] <CIA-7> ffmpeg: Reindent after rr22977. [20:01:54] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs.basty googlemail com>. [20:01:55] <CIA-7> ffmpeg: lucabe * r22979 /trunk/libavdevice/v4l2.c: Simplify some output messages in the v4l2 input device [20:01:56] <CIA-7> ffmpeg: lucabe * r22980 /trunk/libavdevice/v4l2.c: Reduce the verbosity of the v4l2 input device [20:01:56] <CIA-7> ffmpeg: stefano * r22981 /trunk/libavutil/ (error.c error.h): [20:01:57] <CIA-7> ffmpeg: Drop AVERROR_NOTSUPP at the next major bump, use AVERROR(ENOSYS) [20:01:57] <CIA-7> ffmpeg: instead which is semantically equivalent. [20:02:10] <jai> not cool [20:02:24] <BastyCDGS> what is not cool? [20:02:33] <jai> the flood [20:02:45] <CIA-7> ffmpeg: Avoid to show bogus values, which may confuse both the human and the [20:02:45] <CIA-7> ffmpeg: machine reader. [20:02:45] <CIA-7> ffmpeg: Based on a patch by Robert Kr?ger $(echo lsvfhfs(a)tjhobm7.ef | tr "b-za" "a-z"). [20:02:45] <CIA-7> ffmpeg: stefano * r22984 /trunk/ffprobe.c: Reindent after the last commit. [20:02:45] <CIA-7> ffmpeg: cehoyos * r22985 /trunk/libavformat/riff.c: [20:02:45] <CIA-7> (8 lines omitted) [20:02:47] <BastyCDGS> should I pastebin updated code? [20:02:50] <jai> BastyCDGS: also, good that you got it working :) [20:02:50] <ramiro> tell CIA-7 to use pastebin [20:03:05] <jai> BastyCDGS: if it works, then send the patch right? [20:03:09] * mru kicks CIA-7 [20:03:10] <CIA-7> ow [20:03:19] <BastyCDGS> I see an image but colors are wrong [20:03:23] <BastyCDGS> image itself is perfect [20:03:49] <jai> palette ordering is correct i assume? [20:04:40] <BastyCDGS> when I write 0xFF0000 to *dst I get blue background [20:05:00] <BastyCDGS> ham decoding does that way [20:05:22] <BastyCDGS> where I'm not sure is ham_pal [20:05:39] <BastyCDGS> it's PIX_FMT_BGR32 [20:06:22] <BastyCDGS> s->ham_palbuf[i] = AV_RL24( avctx->extradata + i*3 ); [20:06:29] <BastyCDGS> remember that ham_palbuf goes into *dst [20:07:25] <BastyCDGS> AV_RL24 should put if i=0 and extradata[0] = 0xFF0000 a 0x0000FF value into ham_palbuf[i] right? [20:08:52] <CIA-7> ffmpeg: jai_menon * r22988 /trunk/libavutil/log.h: Fix typo. [20:28:44] <BastyCDGS> I got it [20:28:48] <BastyCDGS> it's perfect now! [20:29:07] <BastyCDGS> HAM6/8 works!!!!!!!!!!!!!!!!!!!!!!!! [20:29:08] <BastyCDGS> yeah!!!!!!!!!!! [20:29:10] <BastyCDGS> party time! [20:40:47] * Compn waits patiently for ffmpeg to get files in rar/zip support [20:41:00] * Compn should put it up as qual task :) [20:41:47] <pJok> Compn, patch welcome ;) [20:45:08] <_av500_> Compn: why stop there, make it play alt.binaries.... [20:45:30] <reddwarf> hi [20:46:25] <reddwarf> I'm having problems with a lot of apps trying to compile with post-r22965 ffmpeg versions [20:46:50] <reddwarf> "/usr/include/libavutil/common.h:154: error: 'UINT64_C' was not declared in this scope" [20:47:34] <reddwarf> it seems that macro is defined or not depending of __STDC_CONSTANT_MACROS being defined before stdint.h is included [20:47:51] <reddwarf> so probably it's not a good idea to use it in a header? [20:47:58] <mru> it's a very good idea to use [20:48:00] <mru> it's standard C [20:48:15] <mru> you might as well say it's not a good idea to use string constants [20:48:19] <mru> or arrays [20:48:24] <mru> or pointers [20:48:36] <mru> or any arbitrary feature you broken compiler/libc doesn't support [20:48:39] <j-b> pointers are bad [20:48:44] <_av500_> pointers are dangerous! [20:48:44] <j-b> arrays too. [20:48:48] <j-b> they are! [20:48:59] <j-b> VB.Net for everyone! [20:49:05] <mru> guess what, living is dangerous [20:49:07] <mru> you might die [20:49:12] <Compn> Implementation of AVFilter infrastructure and various audio filters <~~ is this 'in progress'? [20:49:14] <mru> in fact, I can guarantee you will [20:49:17] <_av500_> pointers can dangle and array never know when to stop [20:50:05] <reddwarf> but if I have to trust http://linux.die.net/man/3/uint64_c the macro is not always defined [20:50:24] <mru> trust the offical spec [20:50:58] <mru> http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html [20:50:59] <reddwarf> this can sound stupid, but can give me you a link please? [20:51:03] <reddwarf> thanks [20:51:31] <mru> no mention of conditional definition there [20:56:35] <BastyCDGS> HAM6/8 support patch submitted to ml [20:56:41] <BastyCDGS> works like a charm for me ;) [21:01:07] <pJok> av500, why not play .torrents right away? [21:01:37] <mru> torrents don't work like that [21:01:48] <Tjoppen> BastyCDGS: that sounds just like the thing that a friend of mine would find awesome, since he's fan of 80's hardware and such [21:01:59] <reddwarf> the stdint.h header from glibc says the "ISO C99" specifies the definition should be conditional [21:02:00] <pJok> mru, i know [21:02:13] <mru> reddwarf: that's a lie [21:02:21] <reddwarf> following the draft from Wikipedia: http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf it seems true [21:02:33] <mru> don't believe wikipedia [21:02:35] <lu_zero> yawn [21:02:37] <reddwarf> the official standard isn't free, true? [21:02:49] <mru> the one I linked is the official standard [21:02:54] <lu_zero> j-b: you are sick [21:02:57] <reddwarf> well, it's a link to a PDF from open-std.org [21:03:09] <mru> don't trust drafts [21:03:13] <j-b> lu_zero: I know. I like you too! [21:03:43] <BastyCDGS> mru, non mod 4 check and handling isn't necessary anymore since number of bits is always divisible by 8/16. [21:03:44] <lu_zero> theheh [21:03:59] <mru> the official iso c99 spec has the exact same text as the SUS document [21:06:28] <reddwarf> ok, I trust you [21:07:40] <reddwarf> have somebody reported this to glibc? [21:07:41] <reddwarf> without a copy of the standard an my poor C knowledge I don't feel as being able to "win" in such a bug report [21:12:52] <Kovensky> indeed, gl fighting with drepper [21:13:00] <mru> reddwarf: are you building a c++ app? [21:14:53] <reddwarf> I saw the problem in more than a single openSUSE package... right now I'm looking at Amarok: yes, C++ [21:15:12] <mru> that could have different rules [21:15:24] <mru> c++ is a totally different language from C [21:15:32] <mru> unfortunately part of the syntax is confusingly similar [21:15:51] <BBB> do we need to include <stdint.h> for the macro to work? [21:16:12] <mru> of course [21:16:17] <mru> it's defined there [21:20:23] <reddwarf> so it could be that C++ really needs __STDC_CONSTANT_MACROS? [21:20:28] <BastyCDGS> just updated my HAM6/8 patch, please ignore the previous only [21:20:44] <mru> reddwarf: possibly, I don't the c++ spec on hand [21:20:45] <janneg> reddwarf: yes [21:21:00] <mru> but there's nothing we can do about that [21:21:04] <janneg> at least with the current spec [21:21:10] <mru> it would be an error for us to define that macro [21:21:32] <mru> since that might mess with the calling app in some way [21:22:03] <janneg> no idea if it's included in C++0x [21:22:35] <reddwarf> and even if defined in the header, a C++ app could include stdint.h before common.h and your definition would have no effect [21:23:19] <reddwarf> change it for a manual ULL suffix is an option? [21:24:25] <mru> ull might not do what you want [21:26:34] <janneg> C++0x should have a C99 compatible <cstdint> [21:27:06] <BastyCDGS> yes you also can still include in C++ the gold <stdint.h> stuff [21:28:19] <bcoudurier> hi guys [21:28:47] <Dark_Shikari> hi bcoudurier's onjoin script [21:33:22] <bcoudurier> hello Dark_Shikari [21:34:06] <reddwarf> well, not a nice situation... any advice? be it for libavutil or apps that use it? [21:34:27] <BastyCDGS> HAM support indentation patch submitted to ml [21:39:08] * Kovensky awaits for CHEESE support [21:39:32] <lu_zero> reddwarf: problems with the inline functions? [21:40:29] * lu_zero reads up there... [21:40:37] <lu_zero> damn I NEED a working bx... [21:40:51] <janneg> reddwarf: libav* uses C99 if you want to use it from C++ you're on your own [21:44:00] <reddwarf> do you think a local openSUSE patch to ffmpeg to use ULL instead of UINT64_C would break something knowing we just use GNU tools and only on x86 and x86-64? [21:44:55] <_av500_> reddwarf: what package is that? [21:44:55] <janneg> reddwarf: where's the problem defining __STDC_CONSTANT_MACROS before includeing libav* headers? [21:45:33] <reddwarf> just less work: a single patch vs multiple patches [21:45:53] <bcoudurier> LL is different than UINT64_C [21:46:03] <reddwarf> the one from http://packman.links2linux.org/package/ffmpeg [21:46:17] <lu_zero> reddwarf: you might patch the pkgconfig file and be happy... [21:46:48] <janneg> reddwarf: 23:24 <@mru> ull might not do what you want [21:48:32] <reddwarf> but if I limit myself to x86 and x86-64 it's still not safe? no idea of what the difference between ULL and UINT64_C is... [21:48:42] <reddwarf> yes, the pkg-config idea is not bad [21:48:51] <mru> that's a *very* bad idea [21:49:13] <lu_zero> mru: which one and why? [21:49:17] <mru> pkgconfig [21:49:22] <reddwarf> for sure there including libav* without using pkg-config, but that would be less [21:49:29] <BastyCDGS> reddwarf what is exactly the problem here that you want to do this? [21:49:30] <mru> you'll get different behaviour depending on whether the caller uses pkgconfig or not [21:49:57] <lu_zero> if the caller doesn't use pkg-config... well... [21:50:08] <lu_zero> the caller is using C++ already [21:50:23] <mru> if the caller doesn't use pkgconfig, then the caller is smart and should not be punished [21:50:23] <janneg> and -D__STDC_CONSTANT_MACROS is unecessary for C99 apps [21:50:41] <mru> in fact, defining that in C99 has undefined behaviour [21:50:53] <mru> it's reserved namespace you're not allowed to step on [21:51:37] <lu_zero> mru: not using pkg-config means that the caller is using some kind of euristic [21:52:07] <mru> not at all [21:52:12] <mru> it means the caller is doing the right thing [21:52:19] <mru> #include <libavcodec/avcodec.h> [21:52:19] <mru> done [21:52:48] <lu_zero> #include <libavcodec/avcodec.h> isn't enough... [21:52:51] <lu_zero> and you know it =P [21:52:57] <mru> not enough for what? [21:53:04] <mru> not for lavf of course [21:53:07] <_av500_> it is enough here [21:53:09] <mru> it was an example [21:53:29] <mru> you should of course include the headers that declare the stuff you need [21:53:31] <lu_zero> _av500_: how so O_O? [21:54:09] <_av500_> lu_zero: ? [21:54:09] <BastyCDGS> just a question... [21:54:26] <BastyCDGS> here's a list of other IFF formats which do pix/snd, what do you think of making a demuxer/decoder for them? [21:54:28] <BastyCDGS> http://lclevy.free.fr/amiga/formats.html [21:57:31] <lu_zero> _av500_: just including the header in an empty file and feeding gcc is something that checks for presence [21:58:08] <_av500_> empty? [21:59:01] <lu_zero> _av500_: we were talking about having a way to check for libavsomething [21:59:08] <lu_zero> isn't it ^?^ [22:00:00] <_av500_> we were talking about what is needed besides including libavcodec/avcodec.h, no? [22:00:08] <_av500_> like e,g, pkgconfig [22:01:23] <BastyCDGS> regarding HAM, I just read that there's also HAM4/5: http://www.winfuture-forum.de/index.php?showtopic=65125&st=15 [22:01:41] <BastyCDGS> If you wish I support them also I need some files for testing... [22:07:15] <lu_zero> pkg-config --cflags sometimes is helpful indeed (luckily we _do_ not need that for ffmpeg though) [22:08:22] <mru> if that's "helpful" you're dealing with a very, very broken package [22:13:25] <reddwarf> well, I think I have an example where pkg-config cflags is useful [22:13:53] <reddwarf> in GNU libc and libpthread provide duplicated functions, thead safe and not thread safe [22:14:17] <mru> you're wrong [22:14:35] <reddwarf> ? [22:14:44] <mru> pkg-config isn't useful [22:14:45] <mru> ever [22:15:23] <lu_zero> mru: the idea of having a small tool that tells you if a package is available and how to link to it is good [22:15:30] <reddwarf> if a library if compiled with -pthread it will use the functions from libpthread at compile time [22:15:36] <mru> lu_zero: no it's not [22:15:49] <mru> something is available if the headers and libs exist [22:16:02] <lu_zero> and then? [22:16:03] <reddwarf> but if an app doesn't uses pthread directly it will not use -pthread if pkg-config doesn't says it [22:16:04] <mru> libs should link to whatever they need [22:16:18] <mru> -pthread is not a standard compiler flag [22:16:24] <reddwarf> since libc will be before libpthread at link time will not the library fail? [22:16:24] <mru> what if you're not compiling with gcc? [22:16:38] <mru> besides, there are no such duplicate functions [22:16:50] <BastyCDGS> I made a screenshot showing ffmpeg an HAM8 image ;) [22:16:51] <BastyCDGS> http://www.freeimagehosting.net/uploads/65b09211c2.png [22:16:58] <BastyCDGS> but wonder why it got such small [22:18:49] <kierank> i can't tell if the comments on that livejournal post are trolls or genuine [22:18:54] <BastyCDGS> uploaded it to my hp: http://www.cdgs-crew.com/HAM.png [22:18:59] <BastyCDGS> here is it in original size ;) [22:21:42] <reddwarf> both nm -D /lib64/libc.so.6 | grep ' open$' and nm -D /lib64/libpthread.so.0 | grep ' open$' say the libraries export an open() function [22:24:45] <lu_zero> readelf -s states that libpthread.so's open is und... [22:25:29] <reddwarf> here it returns: " 482: 000000000000e380 128 FUNC WEAK DEFAULT 14 open" [22:26:08] <reddwarf> being 14 the .text section [22:27:13] <reddwarf> Linux with GNU tools, could be different in other systems [22:27:50] <lu_zero> readelf -s /lib/libpthread.so.0 | grep open 22: 0000000000000000 0 FUNC GLOBAL DEFAULT UND fopen(a)GLIBC_2.2.5 (9) [22:28:43] <reddwarf> fopen is indeed undefined also here, but open isn't [22:28:58] <BastyCDGS> fopen??? [22:29:08] <BastyCDGS> how that can be? [22:29:26] <lu_zero> reddwarf: right =P [22:30:13] <mru> first of all, notice that those definitions are not global [22:30:41] <reddwarf> the thing is that an app will add libc and then libA, and then libA will add libpthread... since the symbol resolution order is global, pthread function will never be called [22:30:42] <mru> and they are weak [22:30:52] <mru> will never take precedence over a non-weak definition [22:31:02] <reddwarf> libc also defines it weak [22:35:52] <reddwarf> the fact is I never saw an app fails because of this, but in theory couldn't it fail since the functions libA sees at compile time are thread-safe and at runtime non thread-safe? [22:36:41] <lu_zero> at compile time it cannot see it at all =) [22:39:39] <mru> those functions are there make those calls cancellation points for threads [22:57:26] <reddwarf> someone gave me a complicated explanation about this... but yours make more sense! [22:59:20] <mru> I'm not sure of the mechanism by which the pthread ones override libc [22:59:26] <mru> but it's not as simple as linking order [23:18:15] <BastyCDGS> one question is there already support for color cycling in libavfilter? [23:18:22] <BastyCDGS> I mean shuffling around color indices [23:18:58] <BastyCDGS> it should feature the following: choose start/end color indices set a time when the next shift goes [23:19:15] <BastyCDGS> and decide if shuffle forward/backward/pingpong/random [23:23:55] <saste> BastyCDGS: that should be pretty easy to implement [23:24:17] <BastyCDGS> just want be sure before I start doing it that it just doesn't already exist [23:26:04] <BastyCDGS> http://home.comcast.net/~erniew/lwsdk/docs/filefmts/ilbm.html [23:26:15] <BastyCDGS> regarding this read: 4. Nonstandard Data Chunks

1 0

IRC log for 2010-04-27
by irc＠mansr.com 28 Apr '10

28 Apr '10

[04:48:56] <pengvado> suppose I want a very low latency vlc reader. it gets bits one by one, and must return a decoded symbol as soon as the bits so far uniquely specify one. [04:49:00] <pengvado> what's the best way to do that? [04:49:06] <pengvado> the obvious way is to replace SHOW_UBITS, SKIP_BITS, LAST_SKIP_BITS, UPDATE_CACHE with some custom implementations and then call GET_VLC. [04:49:47] <pengvado> but I can't do that in the same file as anything else, since it destroys those macros. [05:07:16] <Dark_Shikari> why would you need a low latency reader? [05:10:02] <pengvado> cabgt [05:10:30] <pengvado> the jvt guys explained it all wrong [05:11:12] <pengvado> I would explain it as: build a pair of huffman trees with different transition probabilities. read from one, write with he other. [05:12:12] <pengvado> and it's the encoder that needs the low latency bitstream reader. the decoder can use the ordinary get_vlc. [05:12:56] <Dark_Shikari> o.o0.o0o.0o. [05:13:11] <Dark_Shikari> why the hell does the encoder need a bitstream reader [05:13:12] <Dark_Shikari> my brain hurts [05:14:13] <pengvado> because the groups are variable size. it treats the sequence of decisions-to-be-arithcoded as a bitstream, and reads huffman tokens from it. then it codes them with a different huffman table. [05:14:48] <Dark_Shikari> ahhhhhh [05:14:57] <Dark_Shikari> so which do you think is more promising for ffv2 [05:15:01] <Dark_Shikari> this or auto-sorting vlc tables? [05:15:21] <pengvado> since you get to pick 2 trees and the bijection between their leaves, you get lots of degrees of freedom even with tiny trees, and thus get remarkably close to the ideal entropy. [05:16:01] <pengvado> auto-sorting is only useful if you don't already know which vlcs will be more common than which others [05:16:26] <Dark_Shikari> but doesn't that change all the time? [05:17:10] <pengvado> not for lpc residual values. bigger values are rarer. period. [05:17:31] <Dark_Shikari> oh, so you're not going to do the 2x2 block VLCs with this [05:17:35] <Dark_Shikari> I see [05:18:16] <pengvado> 2x2 block VLCs are fine for a fast mode, but they necessarily coarsen the neighbor context. [05:18:36] <Dark_Shikari> ah k [05:18:42] <Dark_Shikari> so fast mode can be 2x2 block VLCs [05:18:45] <Dark_Shikari> slow mode can be CABGT [05:18:52] <Dark_Shikari> with the goal being to make the slow mode still Not Very Slow [05:44:05] <pJok> mornings [06:08:13] <jai> morning [06:08:37] <BastyCDGS> good morning jai [06:08:49] <BastyCDGS> had you a nice sleep? [06:09:06] * BastyCDGS wonders why voice mode is away from me again...isn't that stored permamently? [06:09:24] <wbs> you need to identify to nickserv [06:12:05] <BastyCDGS> done [06:12:35] <BastyCDGS> have I to reopen ffmpeg-devel to get v back? [06:17:45] <BastyCDGS> jai, nickserv reg done etc. and logged in but still not v mode [06:17:49] <BastyCDGS> maybe you have to readd me? [06:18:34] <BastyCDGS> btw, a nice article about dark shikari on heise [06:18:36] <BastyCDGS> http://www.heise.de/meldung/Freier-H-264-Encoder-x264-nun-offiziell-Blu-ray… [06:19:13] <Dark_Shikari> BastyCDGS: our media storm was rather effective [06:19:18] <Dark_Shikari> we got on dozens upon dozens upon dozens of sites [06:19:37] <BastyCDGS> seems to be ;) [06:19:40] <BastyCDGS> congratulations [06:20:53] <Dark_Shikari> all you have to do is say "blu-ray" and you're on the news [06:21:22] <BastyCDGS> lol or HDTV :D [06:21:28] <BastyCDGS> or 3d cinema ;) [06:21:40] <Dark_Shikari> or "google" [06:21:55] * BastyCDGS yells blu-ray [06:22:08] * BastyCDGS and waits for his news article...waiting...waiting...waiting... [06:22:31] * BastyCDGS wonders that there's still no article about me :D [06:23:13] <Dark_Shikari> yes, you have to yell _on slashdot_ [06:23:38] * BastyCDGS kicks slashdot [06:27:42] <pJok> Dark_Shikari, congrats with the bluray capability :) [06:28:37] <Dark_Shikari> sadly I didn't actually code much of it :) [06:29:02] * Dark_Shikari just wrote VFR ratecontrol for 1/2-pass ABR [06:29:11] <Dark_Shikari> And patchreviewed for hours on. [06:29:13] <Dark_Shikari> *on end. [06:29:30] <pJok> you still did some work ;) [06:29:36] <BastyCDGS> well then you can turn on now to crack the AACS ;) [06:29:50] <Dark_Shikari> we're about encoding, so we don't do AACS :) [06:30:03] <BastyCDGS> I said crack it, not doing AACS :P [06:30:34] <Dark_Shikari> I mean cracking too [06:32:54] <BastyCDGS> then it's upon ffmpeg to crack AACS? :D [06:33:26] <Dark_Shikari> libbluray [06:33:49] <BastyCDGS> wooooooow, what a great c64 demo [06:33:50] <BastyCDGS> http://www.youtube.com/watch?v=M-qEzv_IxuU [06:33:59] <BastyCDGS> 320x200 in 16 colors [06:34:00] <merbzt1> BastyCDGS: cracking AACS implies cracking AES [06:34:38] <saintdev> no it doesn't [06:34:41] <BastyCDGS> that will be very hard [06:34:49] * pJok hands BastyCDGS libspc [06:36:32] <saintdev> that's like saying cracking WEP implies cracking DES. [06:36:48] <Dark_Shikari> AACS is already cracked [06:37:07] <saintdev> exactly [06:37:58] <BastyCDGS> AACS crack => ffmpeg git ;) [06:38:57] <BastyCDGS> merbzt1, AES is only secure if you keep the key secure [06:39:16] <BastyCDGS> and that's what all these copy protection schemes fail upon, they have to deliver the key [06:39:52] <BastyCDGS> anyone watched BluREU yet? [06:40:19] <saintdev> BastyCDGS: the problem is, the designer has to think of _every_ weakness [06:40:26] <saintdev> the cracker has to only find one [06:40:42] <aaronl> watched blureu [06:40:57] <aaronl> i'm not really familiar with the c64 demoscene so i dont know how impressive it really is [06:41:14] <aaronl> but i'm curious how much rom (or disk or tape or whatever) that took [06:41:38] <merbzt1> saintdev: well to me a real crack is when you can decrypt without the having a key issued by the bluray authority [06:42:02] <saintdev> merbzt1: true, but that in no way implies cracking AES. [06:42:17] <BastyCDGS> try entering as AES key pw: IHatePirateBay [06:42:22] <Dark_Shikari> merbzt1: encryption schemes are cracked all the time without having the key [06:42:26] <BastyCDGS> if you have little look that's their master key :D [06:42:29] <Dark_Shikari> in fact, that's the primary vulnerability in encryption [06:42:34] <Dark_Shikari> the _algorithm_ is almost always fine [06:42:38] <Dark_Shikari> the _implementation_ is usually faulty [06:42:44] <Dark_Shikari> that's why they tell you to never, ever, ever, ever, ever roll your own [06:42:49] <Dark_Shikari> because you will have holes. [06:42:55] <BastyCDGS> s/look/luck [06:43:27] <merbzt1> saintdev: well one way would be to crack AES [06:43:44] <BastyCDGS> yes many people for example use a 32-bit RNG [06:43:51] <saintdev> yes, but that is unlikely, and probably a waste of time for anyone who tries [06:43:52] <BastyCDGS> for a 128 bit key which reduces effective key size to 32 bit [06:43:57] <aaronl> and i wonder how the rickroll thing was done [06:44:16] <merbzt1> aaronl: precomputed animation [06:44:17] <aaronl> it basically looks like video playback, and i didn't know a c64 could do that [06:45:13] <saintdev> AES has been proven to be very secure by YEARS of research from experts in encryption [06:45:14] <merbzt1> saintdev: what other attack vectors on AACS are there then ? [06:46:22] <saintdev> i'm not familiar enough with aacs to say, but you don't go attacking the strongest part of a safe. [06:46:49] <Dark_Shikari> merbzt1: AACS is not an encryption scheme [06:46:53] <saintdev> you look into the key handling [06:46:53] <Dark_Shikari> that's the attack vector [06:47:00] <Dark_Shikari> normally, in an encryption scheme, you have some encrypted data [06:47:06] <Dark_Shikari> and you give it to person X, who has your key [06:47:08] <Dark_Shikari> and person X decrypts it. [06:47:16] <Dark_Shikari> You are trying to prevent person Y, who doesn't have the key, from reading it. [06:47:18] * BastyCDGS was surprised about that demo too [06:47:26] <BastyCDGS> if that goes on this way, we have in 2-3 years the first H264 decoder running at 1600x1200 :P [06:47:26] <BastyCDGS> on c64 [06:47:38] <Dark_Shikari> With AACS, the blu-ray has some encrypted data [06:47:41] <Dark_Shikari> and it gives it to person X, who has your key [06:47:47] <Dark_Shikari> .... and it doesn't want person X to be able to read it [06:48:01] <Dark_Shikari> The same person who has the key is the person who it doesn't want viewing the data. [06:48:08] <Dark_Shikari> This is physically impossible. [06:48:13] <Dark_Shikari> And this is why all DRM is doomed. [06:48:29] <BastyCDGS> as I mentioned above the key creation itself can be the attack vector, too [06:48:30] <Dark_Shikari> you cannot protect data when someone has physical access to it. [06:48:32] <BastyCDGS> 32-bit RNG etc. [06:49:05] <ohsix> except by the legal threats you can surround its circumvention [06:49:17] <saintdev> ohsix: lol [06:49:19] <Dark_Shikari> only in the US :) [06:49:44] <ohsix> the threat is enough to keep people out without licenses though [06:49:48] <merbzt1> Dark_Shikari: CIplus is most likely not doomed [06:50:06] <Dark_Shikari> ohsix: I'm pretty sure everyone rips DVDs without licenses =p [06:50:06] <BastyCDGS> dark shikari is completely right with this [06:50:11] <merbzt1> it is almost the same DRM model as Bluray [06:50:19] <Dark_Shikari> merbzt1: why isn't it doomed then? [06:50:22] <ohsix> but not everyone makes hardware [06:51:26] <merbzt1> Dark_Shikari: the key is sent over encrypted busses [06:51:52] <saintdev> and that prevented the PS3 from getting hacked? [06:51:57] <saintdev> oh wait, no it didn't [06:51:58] <merbzt1> tinker with the hardware and it will self destruct [06:52:03] <saintdev> how about the Xbox [06:52:10] <saintdev> nope, not that either... [06:52:12] <saintdev> hmmm [06:55:38] <aaronl> i don't think drm is usually intended to "prevent person X from viering the data" in a cryptographic sense; it's just supposed to make it hard, annoying, expensive, etc to do so [06:55:43] <aaronl> *viewing [06:56:06] <aaronl> and to some extent it can be pretty successful at that [06:56:31] <aaronl> if the hardware is out there for a few years before getting hacked, that's probably considered a win [06:56:48] <Dark_Shikari> aaronl: that's because the real purpose of DRM is to prevent legal format-shifting [06:56:51] <Dark_Shikari> not piraacy [06:56:56] <Dark_Shikari> the pirates break the DRM in 3 days and post the result on the pirate bay [06:57:00] <Dark_Shikari> all the pirates get their copies [06:57:11] <Dark_Shikari> The ordinary users who follow the law are screwed. [06:57:15] <Dark_Shikari> Lesson: the law is for suckers. [06:57:38] <aaronl> well as far as i know, nobody is pirating ps3 games yet [06:57:46] <saintdev> just look at ubisoft, lol [06:57:47] <aaronl> and they probably would be if not for the convoluted drm [06:58:03] <Dark_Shikari> aaronl: you sure? [06:58:05] <Dark_Shikari> just head to asia [06:58:15] <Dark_Shikari> Doubt you'll be able to find a disc on the street that's legit in hong kong =p [06:58:27] <Dark_Shikari> Also, microsoft killed over 1 million xbox live accounts the other day for playing with pirated games [06:58:32] <aaronl> okay, maybe that's true [06:58:49] <aaronl> but i doubt i could download a ps3 game on the pirate bay and play it [06:58:58] <aaronl> and that would probably be possible otherwise [06:59:07] <Dark_Shikari> probably not, because they use blu-ray discs [06:59:11] <Dark_Shikari> and most people don't have burners [06:59:30] <aaronl> don't they have hard drives? [07:00:43] <ohsix> drm is the new dolby logo on the hifi [07:02:06] <aaronl> i don't like drm at all, but the world that scares me isn't a world where everything's encumbered by drm that's uncircumventable, because that's obviously bullshit [07:03:48] <aaronl> what i think is more likely is stuff that you can break it if you're really smart and willing to mess arond with fpgas, but pretty much no one has the time and motivation to deal with [07:04:33] <saintdev> IMO CableCARD is a very well designed system [07:04:43] <aaronl> or even things like the iphone where there are somewhat well-polished cracks out there, but then you have to live in fear of retribution from at&t or apple [07:04:58] <aaronl> or microsoft in the xbox example [07:05:31] <Dark_Shikari> I thought the whole point of jailbreaking your iphone was so you didn't have to use AT&T? [07:05:44] <Dark_Shikari> =p [07:06:45] <aaronl> for someone who uses at&t, i don't see the value proposition in jailbreaking it [07:06:52] <aaronl> you can pirate apps, but come on, they all cost like $2 [07:07:12] <aaronl> and once you jailbreak it, all bets are off on things actually working [07:07:23] <Dark_Shikari> yes, jailbraking is not very popular for one reason [07:07:24] <Dark_Shikari> android exists [07:07:32] <Dark_Shikari> If you want to actually do things with your phone, you buy an android [07:07:59] <Dark_Shikari> if you want to live in locked down world where childrens' apps get banned because apple interpreted them as allowing "users to program", you use an iphone. [07:08:39] <Dark_Shikari> And users are mostly choosing the former. Though probably largely because AT&T sucks, and not for any DRM-related reasons. [07:08:42] <saintdev> Dark_Shikari: no game of life either [07:09:22] <Dark_Shikari> saintdev: zomg turing-complete automata [07:10:07] <saintdev> read a blog post about why apple needs to ban the game of life, was quite funny [07:10:48] <Dark_Shikari> the best post was the one about how apple's statement on "original programming languages" was a judgement on the natur of conciousness [07:10:52] <Dark_Shikari> *nature [07:10:56] <kshishkov> because any lifeform in that game on iHardware evolves into Steve Jobs? [07:10:59] <Dark_Shikari> http://joeberkovitz.com/blog/2010/04/08/apple-takes-stance-on-consciousness/ [07:11:14] <aaronl> are you saying that android phones aren't sim-locked? [07:11:24] <aaronl> or just that it's less of an ordeal to unlock them? [07:11:27] <Dark_Shikari> Apple is implicitly taking a position that apps are not “originally written” in the minds of developers, in the form of cognitive representations of problems and their solutions. [07:11:33] <Dark_Shikari> They are taking a position that the brain is not a translation tool for mapping from these representations into C, Objective-C, or what have you. They are subscribing to the theory of a “ghost in the machine”, implying that at some point an app crosses some magical boundary from being an mental thing into a physical thing that is “written” in some definite programming language. [07:11:51] <Dark_Shikari> They are maintaining this because, if they weren’t, every single iPhone app would violate their licensing agreement by virtue of the developer’s mind itself being a tool that produces Objective-C as an “intermediary result”. Apple may thus be the first company to bet the farm on Cartesian dualism. [07:11:57] <Dark_Shikari> <3 [07:12:20] <kshishkov> ok, you'll get A- on your essay for Philosophy class [07:12:28] <Dark_Shikari> that was seriously the best blog post on that issue, ever [07:13:06] <kshishkov> wow, Ubuntu just offered me to upgrade libav* [07:13:14] <saintdev> lol [07:14:01] <Dark_Shikari> yes, to 0.5.1! [07:14:39] <KotH> salut [07:14:53] <kshishkov> shalom [07:16:24] <Dark_Shikari> bonjour [07:16:34] <siretart> buna diminaca [07:16:41] <Dark_Shikari> ni hao [07:16:44] <kshishkov> hejsan [07:17:08] <kshishkov> Dark_Shikari: "nimen hao" would be more correct since you greet a group of people [07:17:27] <siretart> what language is this? [07:17:33] <kshishkov> Chinese [07:17:59] <Dark_Shikari> ohayo [07:18:24] <kshishkov> おっす [07:18:26] <Dark_Shikari> guten tag [07:18:40] <kshishkov> guten morgen here [07:20:24] <pJok> buenos dias [07:20:25] <pJok> i think [07:21:01] <kshishkov> goda morgnar [07:21:30] <pJok> or was it buenos noches? [07:21:48] <kshishkov> that's for "good night" in Spanish [07:22:30] <pJok> then i recalled correctly [07:23:10] <av500> dobro jutro [07:23:32] <kshishkov> добрий ранок [07:33:44] <KotH> aaronl: in .ch and .de, very few phones are sim locked [07:34:04] <KotH> aaronl: in .ch you really have to search for a sim locked phone... [07:48:58] <aaronl> i understand that [07:48:58] <aaronl> i was talking about the US [07:48:58] * aaronl is an americentric bastard [07:49:37] <KotH> the us isnt the world [07:50:02] <kshishkov> indeed [07:50:31] <KotH> .o0(although it's the most agressive race in recent history) [07:50:32] <aaronl> i'm visiting .ch and .de for the first time in july :) [07:50:59] <aaronl> i think i'm pretty well-travelled for an american, but i've definitely neglected europe [07:51:13] <aaronl> so this trip is very exciting [07:51:18] <kshishkov> KotH: not mentioning people who started two world wars and very peaceful Russians [07:51:38] <KotH> dont worry about europe... nothing here beside barbars and raceists [07:51:55] <superdump> barbarians* racists* ? [07:52:07] <KotH> yes, thanks [07:52:15] <kshishkov> superdump: babers and long-distance runners [07:52:25] <superdump> barbers and race drivers [07:53:06] <kshishkov> yep [08:22:49] <wbs> bilboed-pi: in gstreamer, is there any way to measure the amount of time spent in each element of a pipeline? [08:23:24] <bilboed-pi> wbs, non trivially [08:23:56] <bilboed-pi> wbs, are you the one emailing as wl2776 on gst-devel ? [08:24:21] <wbs> nope, i'm not on those lists at all [08:24:36] <bilboed-pi> ok [08:24:59] <bilboed-pi> if it's an element you control, you can do it yourself in your element's chain method [08:25:10] <bilboed-pi> if not... well it gets very tricky [08:25:26] <wbs> no, I don't control it... [08:25:37] <wbs> on the other hand, I control the previous and next elements [08:25:54] <wbs> so in principle, I could grab timestamps at those points and diff them [08:26:52] <bilboed-pi> wbs, also... maybe #gstreamer would be a better place (just realized that). mru's tourette syndrom might start kicking in otherwise :) [08:27:13] <wbs> probably. just checking if there's something obvious I've missed :-) [09:49:42] <kshishkov> mate! [09:55:45] <pross-au> Gidday [09:55:58] <pross-au> I heard something about the Ukraine the other day, but now i forget. [09:56:02] <pross-au> It was an interesting factoid. [09:56:35] <kshishkov> you should [09:56:51] <kshishkov> April 26th is not only world international property day [09:57:15] <pross-au> Yeah? [09:57:20] <kshishkov> it's also the date when certain Ukrainian power plant suddenly output yearly norm of electricity [09:57:23] <pross-au> April 25th was our 'Memorial Day' [09:57:44] <BastyCDGS> sorry, internet was away until now [09:57:48] <kshishkov> memorial for what? WWI veterans? [09:57:51] <pross-au> How do you celebrate that anniversary kshishkov ? [09:57:53] <BastyCDGS> hope I didn't miss anything important... [09:57:55] <pross-au> kshishkov: yes [09:58:19] <BastyCDGS> here in belgium there is something similar to a memorial day [09:58:24] <BastyCDGS> but for WW2 [09:58:26] <kshishkov> pross-au: we don't since we can't get more funding for it [09:58:37] <pross-au> Well ours is not called Memorial Day. It's called ANZAC day. [09:58:42] <BastyCDGS> it's even a work-free day here [09:58:46] <pross-au> But there are no more WWI veterans left [09:59:07] <kshishkov> well, here WWI was screwed by 1917 revolutions [09:59:16] <kshishkov> so nobody cares about it much [09:59:21] <pross-au> It should be renamed to AUSCANUKUSNZ day [09:59:24] <KotH> pross-au: you remind me that i wanted to visit the anzac grave yard in turkey... [09:59:50] * kshishkov has not heard about Gallipoli at all [09:59:52] <pross-au> KotH: lots trek there for the 25th April dawn service [10:00:17] <pross-au> Of course, I find it wierd how we only remember back to WWI [10:00:26] <pross-au> Its not like it was our major conflict [10:00:37] <KotH> nope, it isnt [10:00:55] <pross-au> Where are you from again KotH ? [10:00:59] <KotH> kshishkov: it was one of the most blody battles during WWI [10:01:07] <KotH> pross-au: from the other side of the trench :) [10:01:16] <pross-au> Awesome [10:01:28] * KotH has lost at least 6 family members there [10:02:06] <BastyCDGS> oh, that's sad KotH [10:02:10] <pross-au> Sorry to hear that [10:02:11] <BastyCDGS> :( [10:02:16] * kshishkov does not know his lieage that far [10:02:19] <kshishkov> *lineage [10:02:38] <pross-au> its only four generations ago kshishkov [10:02:45] <kshishkov> so? [10:03:05] <pross-au> thats nothing! a drop in the bucket as we say here [10:03:26] <kshishkov> well, my grandparents know a little about their parents but that's all [10:04:42] <pross-au> thankfully we have an excuse here [10:04:54] <kshishkov> same excuse here [10:05:04] <pross-au> 200 odd years is enough :P [10:06:06] <kshishkov> here we had 1937-1939 [10:06:23] <kshishkov> and 1917-1921 [10:07:13] <BastyCDGS> my brother from my grandmother was shot down from behind while walking over a street by the nazis [10:07:23] <BastyCDGS> s/my/the [10:07:26] <pross-au> Is there mandatory service in the Ukraine? [10:07:40] <kshishkov> for what? [10:07:47] <pross-au> The armed services? [10:07:54] <kshishkov> ah, of course [10:08:01] <pross-au> Voluntary here [10:08:19] <pross-au> there was constription in WW2 [10:08:38] <kshishkov> IIRC everybody here is still considered as military reserve till his death [10:08:41] <pross-au> (that means forced service) [10:09:13] <kshishkov> and we have conscription too of course! [10:09:15] <pross-au> *conscription [10:09:40] <BastyCDGS> well I'm afraid that if it comes hard on hard this will be just in every state handled this way [10:09:52] <pross-au> Yes BastyCDGS [10:10:07] <pross-au> Hence the FFmpeg Army [10:10:24] <BastyCDGS> yes we transcode their weapons to flowers ;) [10:10:47] <kshishkov> try prying a shotgun from mru's hands first [10:11:16] <pross-au> more like transcoding digital feed from UCAS flights [10:12:49] <BastyCDGS> well FFmpeg already helps on this ;) it allows us transcoding videos which show cruelty of war and hand that to people who couldn't play that format otherwise :) [10:13:03] <BastyCDGS> so they awake what's really happening [10:14:10] <pross-au> Cruetly would be watching that in Theora [10:14:21] <pross-au> but i digress [10:16:09] <kshishkov> we have "Victory" day on 9th of May for the ending of WWII and remembering people who fought there [10:17:56] <BastyCDGS> http://noviomagus.tripod.com/background-history.htm [10:18:41] <kshishkov> it was even worse for Ukraine [10:22:55] <BastyCDGS> belgium has holiday on 9th november (end of ww1) [10:24:51] <FUautotools> 9th? [10:25:13] <BastyCDGS> 11th sorry [10:25:31] <BastyCDGS> was mixing with 9-11 ;) [10:25:50] <kshishkov> hmm, wasn't Belgium the place where Ypres is situated? [10:26:10] <pross-au> BastyCDGS: thats because the rest of world say DAY then MONTH [10:26:41] <kshishkov> pross-au: in his case it's 11.11 [10:26:56] <pross-au> 11:11 on the 11th of November. Yes we do that too. [10:26:57] <BastyCDGS> yes i was mixing with WTC somehow ;) [10:27:03] <BastyCDGS> just swapping day/month [10:27:22] <BastyCDGS> and yes ypres is be [10:27:41] <kshishkov> nice gases you did have there [10:28:37] <BastyCDGS> gases? [10:29:21] <kshishkov> http://en.wikipedia.org/wiki/Mustard_gas [10:29:27] <FUautotools> gasses [10:30:53] <BastyCDGS> i understood the word but I dunno what gases he means [10:31:29] <kshishkov> look at the section "Use" or guess why that gas is sometimes called "Yperite" [10:32:34] <BastyCDGS> oh you did mean nerve gases [10:33:01] <FUautotools> Chlorine and Mustard gas are not nerve gases [10:35:59] <BastyCDGS> I don't have expertise on this sorry [10:36:15] <BastyCDGS> I really don't differ internally between poison/nerve gases [10:36:34] <kshishkov> ok, then you can continue telling us about Amiga stuff [10:37:26] <BastyCDGS> well I don't want that you interrupt your topic just because of me ;) [10:40:44] <BastyCDGS> maybe you can just teach me something about this [10:41:36] <KotH> pross-au: no need to be sorry, it was war time... and they defendet their homes, fully knowing what will happen [10:42:22] <BastyCDGS> btw, I'm just reading than saddam was also using mustard against iran [10:42:27] <BastyCDGS> s/than/that [10:51:00] <pross-au> Amiga? [10:51:25] <BastyCDGS> what's with the Amiga? [10:51:44] <av500> pross-au: that used to be a computer [10:51:47] <pross-au> I dunno [10:51:54] <pross-au> Duh! [10:51:54] <BastyCDGS> oh you didn't know it? [10:52:08] <BastyCDGS> it was the most-known home computer in late 80's/first half 90's [10:52:15] <BastyCDGS> and widespread [10:52:19] <pross-au> Yes yes. Was somebody talking about amiga support [10:52:29] <BastyCDGS> in ffmpeg? [10:52:44] <pross-au> 20:40:20 <@kshishkov> ok, then you can continue telling us about Amiga stuf [10:52:45] <BastyCDGS> I'm currently responsible for proper decoding of amiga specific formats ;) [10:52:56] <pross-au> IFF HAM support [10:52:59] <pross-au> Nice [11:08:39] <KotH> ffmpeg - resistance is futile, your codec will be assimilated [11:09:01] <kshishkov> say that to x264 [11:09:50] <BastyCDGS> aXximilated 264 times? [11:09:51] <twnqx> the worst thing about that is the now cyclic dependency >_> [11:10:15] <twnqx> (unless you build lonly libx264 first, then ffmpeg, then the x264 executable) [11:20:00] <pross-au> its only a cyclic depenancy for as long as '264 stays current. [11:21:01] <pross-au> h.265 is coming. then the process will start all over again. [11:21:23] <spaam> pross-au: just wait for h266! [11:21:29] <mru> h666 [11:22:06] <spaam> omg the codec for the beast? [11:22:08] <pross-au> spaam: we will have run out of oil and uranium by then [11:22:28] <mru> uranium, hardly [11:22:30] <merbzt1> maybe even electrons [11:22:33] <pross-au> surely that'll be vp66 [11:23:18] <pross-au> theres only 100 years supply of it or sth] [11:24:00] <mru> and don't forget about the coal [11:24:05] <mru> there's load of that [11:24:14] <mru> unfortunately it's very filthy stuff [11:24:39] <pross-au> We have heaps of coal and uranium here :P [11:25:33] <pross-au> No guess as to which communist country it is all being sold to... [11:27:04] <iive> pross-au: no, the currently mined one would be enough for that period, if not recycled. and there is more out there. [11:28:23] <pross-au> iive: cool. so that 'earth hour' thing where everyone turns their lights of to conserve energy is just a crock of shit? [11:28:34] <iive> yes [11:29:30] <pross-au> Mr Fusion for everybody [11:30:27] <iive> it's made up by activists who live in country that burns coal to produce electricity. Same one that have more fission reactors on ships than on ground [11:31:29] <pross-au> The iron is that the west wants developing countries to curb their energy use. [11:31:37] <pross-au> Irony [11:32:07] <iive> well, west doesn't want these countries to have any kind of reactors. [11:34:13] <KotH> well, the west doenst want these countries to develop at all, so that they can continue to exploit them [11:35:16] <kierank> they also are nervous about unstable governments having access to nuclear material [11:35:57] <KotH> unstable goverments? like teh US? israel? russia? [11:36:22] <kierank> north korea, iran [11:36:48] <pross-au> Unstable, as in out of the US and NATO's sphere of influence. [11:37:06] <iive> kierank: these both have VERY stable governments. haven't changed in decades. [11:37:16] <KotH> kierank: north koreas goverment has a longer record of staying on the same line than most "western" goverments [11:37:21] <pross-au> Yep [11:44:12] <frankuva> av_open_input_file works with rtmp:// but i am unable to define the filename to play on that rtmp url... how can i do that? [11:47:35] <KotH> by asking in the right channel [11:48:17] <frankuva> you mean #ffmpeg? i've asked there and got no reply. thanks for your warning i won't be disturbing you in this channel [11:48:51] <BastyCDGS> maybe there was nobody able to answer your question [11:48:59] <BastyCDGS> just try it there later again [11:49:17] <BastyCDGS> remember ffmpeg is huge, not everyone knows everything in ffmpeg [11:50:33] <merbzt1> frankuva: best bet is to ask on the mailinglist [11:50:48] <frankuva> ok thank you all [11:51:30] <BastyCDGS> btw, try to open a file the way you would do with a http:// also [11:51:45] <BastyCDGS> I don't know about rtmp and alike, but if it's an url it probably has a similar scheme [11:54:43] <frankuva> i have to run "C" version (code) of this command line: "-i station.flv -f flv rtmp://site.com/station". i am unable to specify that -i parameter so just calling it like http:// does not work because remote server says :" file not found" since i am unable to tell it station.flv" [11:56:35] <BastyCDGS> try ...site.com/station#file.ext [11:56:41] <BastyCDGS> if that doesn't work I dunno [11:56:47] <BastyCDGS> or station/file.ext [11:59:44] <av500> http://alvarez.site.ac.upc.edu/hdvideobench/ffmpeg-2dwave.html [12:00:24] * BastyCDGS thinks of doing a parallel IFF-ILBM decoder :D [12:00:28] <BastyCDGS> one core = one plane [12:01:05] <BastyCDGS> just a #pragma omp parallel for would do it probably ;) [12:01:12] <mru> bwaahhahaa [12:01:15] <av500> omg parallel? [12:06:25] <pentanol> hi I'm evaluating why ffmpeg crached on my arm and what I've http://codepad.org/NGVwmfhk [12:06:44] <pentanol> with that, it well allocate memory in first [12:07:54] <pentanol> but then..... when it tries open input stream and crached there ic = avformat_alloc_context(); [12:08:44] * av500 does not get that pastebin [12:09:15] <pentanol> there on codepad [12:09:47] <kierank> perhaps get rid of all the junk so it is readable ? [12:09:56] <pentanol> here list of commented option in AVOptions [12:12:39] <pentanol> wich of these options really important? [12:12:47] <BastyCDGS> av500 you don't know OpenMP? [12:13:06] <pentanol> it's from./libavcodec/options.c [12:18:30] <mru> BastyCDGS: of course we know of openmp [12:18:43] <mru> we just don't believe it's all it's cracked up to be [12:19:04] <mru> I've only seen it work well on schoolbook examples [12:19:46] <BastyCDGS> that was going to av500 because he asked about parallel omp [12:19:52] <BastyCDGS> sounds like he didn't knew it [12:20:06] <av500> BastyCDGS: ignore what I say :) [12:20:12] <BastyCDGS> lol ok ;) [12:30:22] * KotH sometimes wonders whether some companies do not want to sell anything [12:30:59] <KotH> device A in single pieces: 400EUR, device A in 1000 pcs: 250EUR, equivalent design self made: 150EUR [12:34:53] <av500> 4) profit [12:36:28] <KotH> they wont profit if they dont sell ;) [12:43:53] <kshishkov> sometimes they do wicked things [12:44:13] <kshishkov> like IBM software requiring something of IBM server level to run [12:44:20] <kshishkov> even if intended for PCs [12:45:12] <av500> kshishkov: there might be people at IBM to whom the PC is a novelty concept... [12:46:17] <kshishkov> av500: they are long buried cutted corner down [12:47:01] <av500> big iron ftw! [12:48:16] <KotH> no coold feet in winter anymore! [12:48:35] <kshishkov> av500: elephantine software [12:48:57] <kshishkov> IBM is associated with elefants in some mysterious way [12:49:26] * av500 prefers his bank to run on big iron and not mcaffee installed pcs [12:49:46] <kshishkov> COBOL-driven? [12:49:52] <av500> sure [12:50:11] <av500> but I am biased, my mom used to be an ibm db2 admin [12:50:40] <kshishkov> my friends works as an admin in regional office of one bank [12:51:31] <av500> one day they took away her nice 3270 and gave her a PC emulator, since then pc network downtime was downtime for her too, never happened before... [12:54:13] <kshishkov> no token ring for her anymore? [12:54:28] <av500> no, the "new" pc ethernetwork took all that away :) [12:57:19] <kshishkov> curse you DEC and Ethernet! [12:57:37] <kshishkov> s/DEC/PARC/ [12:57:50] <twnqx> <KotH> device A in single pieces: 400EUR, device A in 1000 pcs: 250EUR, equivalent design self made: 150EUR [12:57:59] <twnqx> do the 150€ cover the time spent as well? [12:58:20] <twnqx> (except that time can actually be fun :P) [13:00:07] <KotH> twnqx: engineering time is paid seperately [13:00:21] <KotH> twnqx: and even if, the engineering costs are less than 100EUR/piece [13:00:43] <twnqx> well, i had a similar effect with my PCBs (the fpga ones) [13:00:49] <twnqx> cost for one: 200€ [13:00:55] <twnqx> cost for twentyfive: 200€ [13:00:56] <twnqx> >_> [13:02:15] <KotH> lol [13:02:35] <KotH> what about tooling costs? [13:12:17] <twnqx> don't have the invoice here [13:12:26] <twnqx> but yeah, ordering more would be cheaper [13:49:34] <BastyCDGS> BBB, have you dealed with my patch in libavformat/iff.c? [13:49:44] <BastyCDGS> seems really you forgotten one [13:49:52] <BastyCDGS> btw, I'm shortly afk [13:59:17] <BBB> spyfeng__: congratulations on your SoC project acceptance! :) [14:11:46] <BastyCDGS> BBB, I'm back for a short time now [14:12:12] <BastyCDGS> do you know which patch I meant? [14:12:19] <BBB> they're applied [14:12:23] <BBB> since 5 seconds ago :) [14:12:43] <BastyCDGS> lol what a synchronity :D [14:14:01] <BBB> also welcome to GSoC :) [14:14:11] <BastyCDGS> thanx... [14:14:11] <BBB> so stefano will help mentoring you right? [14:14:22] <BastyCDGS> yes, although we didn't talk quite some time [14:14:25] <BBB> I guess I'll help where I can, also andoma and mru might be helpful for you [14:14:26] <BastyCDGS> but he said he's pretty busy [14:14:30] <BBB> we'll see how it turns out [14:15:28] <BastyCDGS> but I've to discuss much stuff right now here because of my exams on 12th may [14:15:38] <BastyCDGS> so I'm just looking from time to time sorry for that [14:19:22] <BBB> that's ok [14:24:12] <kshishkov> BBB: what the task? [14:25:19] <BBB> mod files [14:25:22] <BBB> for him [14:25:26] <BBB> spyfeng does MMS [14:25:32] <kshishkov> yes, that's what I meant [14:25:35] <BBB> I'm working wvp2, but not for GSoC [14:25:49] <kshishkov> it's all not for GSoC but for FFmpeg ;) [14:25:50] <BBB> slowly though :) [14:25:55] <BBB> right [14:26:02] <BBB> although $5k would be a nice stimulus package [14:26:11] <kshishkov> tell that to mru [14:26:26] <kierank> kshishkov: http://news.bbc.co.uk/1/hi/world/europe/8645869.stm [14:26:27] <av500> gee, ppl only code for money these days? [14:27:35] <kshishkov> kierank: I don't care, even more than I did not cared before [14:27:49] <kshishkov> av500: unless they can code for fun [14:28:20] <av500> kshishkov: is there an unkrainen gov tv channel, this is must fun to watch [14:28:58] <BBB> ? [14:29:09] <BBB> most if not all of my code was coded for no money [14:29:22] <BBB> I'm just saying it's nice to get a dinner check at times :) [14:30:35] <kshishkov> av500: I don't watch TV [14:30:53] <kshishkov> BBB: yes, except for us it's cash-based economy [14:31:41] <av500> mru: you have a nice url for why gcc and neon intrinsics sucks? [14:32:39] <kierank> kshishkov: cheques are too advanced for .ua ? [14:33:38] <mru> av500: http://hilbert-space.de/?p=22 [14:34:44] <kshishkov> kierank: yes, I've never seen any transaction with a cheque in my life. Cards are spreading slowly though [14:35:25] <av500> card games are good way to transfer money [14:35:47] <mru> I know a guy who earns a living in the casino [14:35:51] <mru> (he works there) [14:36:12] <kshishkov> mru: he could earn a fortune in casino if he _owned_ it [14:36:33] <av500> kshishkov: not always, casino in formar eastern germany are all going bust [14:37:03] <mru> I have a business plan: people will come to my house and give me their money [14:37:04] <av500> somehow ex-socialists dont like to gamble [14:37:07] <mru> how could that possibly go wrong? [14:37:39] <kshishkov> mru: by omitting a clause of not taking anything from your house afterwards [14:38:11] <av500> mru: depending on what services the "house" provides, it might work [14:38:24] <mru> losing your money of course [14:38:39] <kshishkov> sounds like tax office [14:39:41] <av500> mru: thx for the link, coworker is rewriting in asm as we speak :) [14:43:53] <kshishkov> is that hard? even _I_ can write asm [14:44:59] <lu_zero> wbs: who broke ffmpeg as producer lately? [14:45:14] <av500> kshishkov: not hard, ppl are just lazy [14:45:33] <mru> writing asm is much easier than things like c++ [14:46:12] <lu_zero> mru: x86 asm makes me wonder [14:46:37] <mru> even that is easier [14:46:46] <mru> at least reading it is easier [14:46:48] <kshishkov> than writing inline x86 asm [14:47:07] <BBB> so having a table lut[][] which you access as lut[get_bits(..)][plane] didn't make it faster? [14:47:31] <mru> where are those samples again? [14:47:53] <av500> x86 asm makes me think I look at .sect random [14:48:43] <BBB> http://samples.mplayerhq.hu/image-samples/24.iff [14:48:58] <BBB> http://samples.mplayerhq.hu/image-samples/test.iff [14:49:04] <BBB> http://samples.mplayerhq.hu/image-samples/ASH.LBM [14:49:51] <BBB> http://samples.mplayerhq.hu/image-samples/atarist/iff/ [14:50:20] <BBB> BastyCDGS: which one do you use? [14:59:54] <BastyCDGS> Ooze.iff (24bpp) and Heart.ILBM [14:59:57] <BastyCDGS> (8bpp) [15:00:36] <BastyCDGS> BBB, the lut table stuff...lut makes it compared to byte access up to 700-800% faster [15:00:54] <BastyCDGS> but moving calculation of lut table outside function stack doesn't [15:01:05] <mru> can you post the links to those files again? [15:02:12] <BastyCDGS> of course [15:02:52] <BastyCDGS> http://roundup.ffmpeg.org/issue1727 (no HAM/EHB support, some IFF ILBM files decodes incorrectly) [15:02:52] <BastyCDGS> http://roundup.ffmpeg.org/issue1796 (IFF ILBM - bad aspect ratio with FFplay) [15:03:07] <BastyCDGS> they're somewhere in the attachments [15:03:36] <mru> which is which of those? 8/24-bit.. [15:03:46] <BBB> ooze is 24 [15:03:49] <BBB> heart is 8 [15:04:15] <BastyCDGS> exactly as BBB stated [15:04:33] <mru> and you did a few minutes ago... [15:06:07] <BBB> ooze looks weird [15:06:11] <BBB> are we sure that's correct? [15:06:44] <BastyCDGS> I can check it on my original amiga if you wish when I'm at home [15:06:49] <BastyCDGS> but looks correctly to me [15:06:52] <BastyCDGS> it's art not a photo [15:06:57] <BBB> hm... [15:07:01] <BBB> odd lines though [15:08:12] <mru> how am I suppose to benchmark decoding a single frame? [15:08:59] <BastyCDGS> just do after the unsigned i; [15:09:02] <BastyCDGS> START_TIMER; [15:09:15] <BastyCDGS> and at end of decodeplane8/32 [15:09:15] <BastyCDGS> STOP_TIMER("decodeplane32"); [15:09:19] <mru> a single frame isn't enough to be accurate [15:09:30] <BBB> decodeplane8 is called per line [15:09:31] <BBB> it's ok [15:09:31] <BastyCDGS> this function is called around 8000 times then [15:10:04] <mru> I'd prefer a longer sample [15:11:43] <BastyCDGS> for (i = 0; i < 1000; ++) do; ffplay ooze.if; done :D [15:11:50] <mru> no good [15:11:54] <BBB> about 24.2k before patch here (decodeplane8()), 7.8k after [15:11:57] <mru> that only measures the startup overhead [15:12:01] <BBB> now let's try with a lut[][] [15:12:07] <mru> 24k what? [15:12:19] <BastyCDGS> BBB, that's almost the same I got [15:12:22] <BastyCDGS> for 8bpp [15:12:35] <BastyCDGS> if I remember right [15:14:50] <lu_zero> wbs: 46ce50eeadf2d7 broke flux, is it working for you using other streaming muxers? [15:15:32] <BBB> what's bits_per_coded_sample? [15:15:34] <BBB> is it always 5? [15:15:38] <BBB> or can it be 8 or something else? [15:19:26] <BastyCDGS> for 8bpp it can be 1 to 8 [15:19:55] <BastyCDGS> for 24bpp it can theoretically 1 to 24, but practically it's 9 to 24, because 1 to 8 is handled by decodeplane8 [15:21:03] <BastyCDGS> btw, 0 planes are also legal on amiga, it's a 1 color image, thus only black, etc. although I doubt it would make sense to store a file with that ;) [15:21:25] <mru> if it's possible, someone will do it [15:21:42] <kshishkov> and encapsulate into mkv [15:21:59] <BastyCDGS> the code should handle that though, the plane loop is simply not executed at all... [15:22:06] <BastyCDGS> you don't have to write any pixels in that case ;) [15:22:16] <wbs> lu_zero: yeah, it works just fine for me... which part is it that breaks things for you, ssrc or base_timestamp? [15:22:56] <BBB> hmm [15:23:01] <BBB> lut[][] = 8.6k dezicycles [15:23:02] <BBB> amazing [15:23:24] <BastyCDGS> BBB, could you align lut to 64? i.e. cache line? [15:23:29] <BastyCDGS> and check if that changes? [15:23:34] <BBB> umm... [15:23:40] <lu_zero> wbs: probably the bug was in flux [15:25:11] <BBB> no [15:25:11] <BBB> s [15:25:16] <BBB> still 8.6k [15:25:46] <BastyCDGS> I think the reason why the calculation stuff is fastest when done inside loop that it puts all values directly to L1 cache on the fly [15:26:06] <BastyCDGS> and are kept there [15:26:38] <BastyCDGS> while using lut does only puts values to L1 which are read which calls stalls in the loop for each value once [15:27:21] <BastyCDGS> maybe do a objdump -d on both and look on that [15:27:36] <BBB> I can't see what it loads into L1 ;) [15:28:53] <BastyCDGS> mov 0x0,[0x3c+ebp] => will put [03c+ebp] to L1 [15:29:09] <BastyCDGS> same for mov %cl,[0x40+ebp] etc. [15:29:20] <BastyCDGS> so they're directly accessible in the loop without any stalls [15:29:44] <BastyCDGS> have to sign off now, my train back to liege comes in 20 minutes... [15:30:03] <BastyCDGS> I'll be back here around 19:30-20:00 [15:30:08] <mru> you guys don't have mobile internet? [15:30:26] <BastyCDGS> I don't even have a mobile device anymore... [15:30:30] <mru> BastyCDGS: did you see my reply on the ml a few minutes ago? [15:30:55] <BastyCDGS> nope, will read it when home, also in 2 hours [15:30:56] <mru> I might be out tonight btw [15:31:07] <BastyCDGS> oh meeting a sweet girl? ;) [15:31:13] <mru> maybe... [15:31:18] <spaam> nice mru ;) [15:31:18] <mru> no, just some friends [15:31:33] <spaam> mru: you know what you have to do ;) [15:31:37] <mru> some of which are girls [15:31:47] <BastyCDGS> oh an orgy? [15:31:49] <BastyCDGS> SCNR [15:32:41] <BBB> I think gcc screws up [15:32:51] <BBB> let me try something else [15:32:56] <BastyCDGS> ok I'll to go now...otherwise my train will be away [15:32:58] <BBB> I think it recalculates lut[][] eveyr iteration [15:33:03] <BastyCDGS> we'll see again in 2h [15:33:04] <mru> on arm doing the shift in the loop is obviously faster [15:33:06] <BBB> while the first ([plane] is always the same [15:33:13] <mru> since the shift comes for free there [15:33:40] <BastyCDGS> BBB, one last idea [15:33:58] <mru> and gcc isn't very smart about building that table [15:34:01] <BastyCDGS> do a: [15:34:01] <BastyCDGS> const uint32_t lut [] = &decodeplane8_tab[plane]; [15:34:05] <BastyCDGS> and refer to lut [15:34:09] <BBB> I know [15:34:11] <BBB> that's what I'm trying :) [15:34:19] <BBB> I'm looking into where gcc screws up [15:34:27] <BBB> but I changed a header accidently so it's rebuilding my tree [15:34:31] <BBB> takes +/- 3 minutes... [15:34:32] <BBB> :( [15:34:46] <BastyCDGS> ok I'm away...see you soon ;) [15:35:26] <BBB> mru: will get you the x86 numbers in a bit [15:35:30] <BBB> my guess is that it's faster also [15:35:34] <BBB> if you do it right [15:38:21] <mru> my diff: http://pastie.org/937417 [15:42:43] <lu_zero> bug in flux fixed [15:43:41] <BBB> 7.6k to 7.4k now [15:43:47] <BBB> so slightly faster [15:44:05] <BBB> with a 2D lut [15:44:13] <BBB> is that faster on ARM, mru? [15:44:38] <BBB> the shift-in-loop is definitely slower here [15:44:42] <BBB> from 7.6k to ~8.5k [15:45:38] <lu_zero> BBB: what are you doing? [15:45:51] <BBB> doing basty's work :-p [15:48:32] <wbs> lu_zero: good that it was fixable in flux, since i think the rtp muxer is much more standards compliant now [15:50:07] <lu_zero> wbs: if fact I was wondering since the change made sense [15:50:39] <lu_zero> and the fix in flux was quite simple [16:01:46] <mru> BBB: 2d array is fine on arm as well [16:02:49] <mru> and the patch I used http://pastie.org/937467 [16:06:42] <BBB> excellent, that's an exact replica of my patch, more or less [16:06:49] <BBB> ok, let's have him re-do the effort then :) [16:06:53] <BBB> we shouldn't make patches for him [16:06:55] <BBB> that's no good :) [16:09:12] <jai> on that note, i remember justin splitting patches for me at some point [16:09:28] <jai> as a "demonstration" [16:09:43] <BBB> we're doing the actual performance checks for him to show which is fastest [16:09:47] <BBB> he only has to implement that one then [16:09:51] <jai> ah [16:09:59] <mru> he needs to learn proper benchmarking [16:09:59] <BBB> ;) [16:10:06] <BBB> right [16:10:09] <BBB> he claimed this was slower [16:10:12] <BBB> which we didn't believe [16:10:15] <mru> as well as optimising for post-m68k cpus [16:10:15] <BBB> we now show it really is faster [16:10:18] <BBB> when doing it correctly [16:11:10] <mru> the 2d table is only 512 bytes so it fits easily in cache [16:11:19] <mru> there's no way rebuilding it on the fly is going to be faster [16:12:09] <lu_zero> if you don't miss the cache [16:12:17] <mru> it won't miss [16:12:22] <mru> it's 512 bytes [16:12:27] <mru> L1 cache is 16-32k [16:12:39] * lu_zero thinks about perverted cache layouts [16:12:40] <lu_zero> uhmm [16:15:48] <BBB> mru is right, there's no way it could be slower [16:16:08] <BBB> gotta run to a meeting now, I'll revert the int->unsigned parts that are unnecessary in a bit [16:17:16] <mru> do they harm? [16:18:55] <lu_zero> ok, now it's ffplay turn =P [16:19:12] <mru> ffplay is not useful for benchmarking anything other than ffplay itself [16:19:15] <mru> and possible sdl [16:19:15] <lu_zero> the mpeg2 decoder pukes on master but works flawlessly [16:19:26] <lu_zero> mru: yet another issue ^^ [16:19:42] * lu_zero is doing some checks with the rtsp stuff [16:19:43] <mru> yeah, I realised that with your second line [16:21:32] <lu_zero> the seeking is flawless now =) [16:22:50] <BBB> \o/ [16:23:11] <wbs> lu_zero: i have to use -noframedrop for it to work reliably after seeks [16:23:28] <wbs> but that's mainly an ffplay issue I think, probably same as Luca A filed on roundup today [16:26:19] <nfl> BBB: hi could you create a "home document" for ffmpeg on the gsoc site?. that way the accepted students list will be shown. [16:26:26] <lu_zero> yup [16:29:04] <lu_zero> Compn: you wrote something like ffmpeg cannot play $unsupportedcodecidon'tknow in $containeri'mnotaware pointing a sample with no extension... [16:34:23] <jai> that's one of the more retarded melange "features" [16:35:36] <mru> that app is retarded through and through [16:35:49] <mru> what fools wrote it? [16:37:08] <jai> gsoc kids [16:37:11] <jai> and some googlers [16:37:14] <nfl> jai: you have to admit though that the map is cool ;) [16:37:30] <jai> nfl: umm..that's got nothing to do with melange [16:37:50] <jai> nfl: just use the google maps api, its pretty trivial [16:37:54] <nfl> true, i was talking abt the home document [16:38:55] <jai> yeah, i dont see why they can't autogen that based on the org description and data pulled from the db [16:41:39] <nfl> somebody should bug them :) [16:42:21] <jai> what's the point, they tag all UX issues as wontfix [16:43:12] <nfl> why would they do that? [16:44:35] <jai> good question :) [16:49:03] <wbs> lu_zero: the sample compn pointed to was svq3 and qdm in a mov container, you have the same in sample*.mov in DSS, too [16:55:14] <astrange> i don't suppose anyone remembers which mpeg-2 sample uses field pictures? [16:55:17] <astrange> i know one of them does [16:56:13] <mru> maybe the ones in MPEG2/interlaced [16:56:22] <iive> you mean interlace? [16:56:36] <astrange> there's two ways to do interlaced [16:56:50] <astrange> field picture (like h264 PAFF) is much rarer but i found one in there [16:57:00] <astrange> i think it might have been broken_ntsc.mpg [16:57:37] <mru> sounds likely [17:09:34] <peloverde> mru, http://people.xiph.org/~xiphmont/lj-pseudocut/o-response-1.html [17:13:10] <mru> omg [17:13:12] <mru> OMG [17:13:19] <mru> *OH MY GOD* [17:13:48] <elenril> sue him for misspeling your name [17:13:57] <kierank> oh good more drama [17:14:01] <mru> that would be hard [17:14:07] <elenril> Ogg's Good Name << haha [17:14:14] <kierank> holy shit that's long [17:14:23] <mru> and he called mine tl;dr [17:15:51] <Kovensky> <@Myrsloik> I have a hypothetical question for you... [17:15:51] <Kovensky> <@Myrsloik> let's say the company I work at is going to build a bike shed, should I ask what color it's going to be? [17:15:54] <Kovensky> <Plorkyeran> I don't know how you could possibly pass up the chance to argue over the color of a bike shed [17:15:58] <kierank> are the patents for mp4 actually relevant? [17:15:58] <Kovensky> <Plorkyeran> it'd be like a dream come true [17:16:06] <mru> kierank: of course not [17:16:52] <astrange> iirc the only patent on mp4 as a container format is on hinted streaming [17:17:10] <peloverde> I thought BIFS had some patents (not that anyone uses BIFS) [17:17:19] <mru> both of those are totally useless [17:17:35] <mru> and ogg is hardly a replacement for either even if they were useful [17:17:53] <Compn> lu_zero : rtsp://stream.diffusion.ens.fr/2008_10_03_albarede.mov [17:17:53] <Compn> ? [17:18:11] <KotH> Kovensky: please say hi to Myrsloik and ask him whether he is still working on the kknj rips [17:18:20] <Kovensky> KotH: lol [17:19:03] <mru> oh, I get it... monty has no sense of humour [17:19:09] <mru> none whatsoever [17:19:48] <kierank> oh god there's a next iteration of ogg [17:19:54] <Kovensky> "By way of clarification, Ogg is for all codecs." <-- but no non-xiph codecs specify how they should be muxed in that, nor ogg makes any effort to do otherwise [17:19:58] <Kovensky> kierank: yes, there is [17:20:02] <kierank> transOgg [17:21:26] <mru> wtf is wrong with monty? [17:21:36] <mru> does he actually believe the crap he's spouting? [17:22:05] <peloverde> I think he's kind of like Bill Joy who also started out pretty smart then turned into a total crackpot [17:22:26] <mru> like rms [17:22:39] <KotH> who's bill joy? [17:22:40] <mru> only monty wasn't even half as smart to begin with [17:22:45] <mru> KotH: sun guy [17:23:07] <mru> wrote lots of early unix stuff [17:23:15] <peloverde> KotH, Bill Joy was one of the Sun co-founders supposedly wrote BSD TCP in a weekend, also the original author of vi [17:23:32] <mru> and this guy was actually inventing the stuff [17:23:38] <mru> not just plagiarising it like rms [17:24:05] <Kovensky> I need a t-shirt that says "I AM COMMITTEE". <-- loses points for not suggesting "I AM BOSS" [17:24:09] <KotH> hmm.. is the rant worth to read? [17:24:17] <KotH> i mean... it's LOOOOOOOOOOOOOOOOOOOOOOOOOOONG [17:24:38] <mru> he's mostly nitpicking [17:24:40] <KotH> mru, peloverde: thanks [17:24:50] <Kovensky> most of it is quoting mru and nitpicking [17:25:25] <KotH> if it's just nitpicking w/o anything novel to learn, i rather finish my work here than waste my time [17:26:34] <elenril> unfunny troll is unfunny [17:26:48] <elenril> KotH: don't read it, it's boring [17:26:50] <mru> at least I managed to annoy him [17:27:14] * elenril goes back to hacking fortran code [17:27:58] <KotH> elenril: you read it? [17:28:05] <KotH> elenril: even though it was *effort* ? [17:28:13] <elenril> some of it [17:28:45] <mru> "the Google announcement" [17:28:47] <mru> what announcement? [17:29:17] <Kovensky> "It is also not possible to stream live in MP4 at all; the bitstream format simply does not have the feature" <-- well, you can, but with a small delay... right? [17:29:25] <astrange> maybe vp8 is going to use ogg II? [17:29:53] <astrange> i don't get why ogg is supposed to be streamable if it doesn't repeat headers and vorbis has 4KB headers [17:29:59] <mru> Kovensky: mp4 does allow streaming with a delay [17:30:33] <mru> but low-latency streaming with mp4 is impossible [17:30:37] <mru> it wasn't designed for that [17:30:54] <mru> it was designed for low-overhead and easy seeking in disk-based storage [17:30:58] <Yuvi> mru: did you ever contribute to nut? [17:31:02] <mru> and there it excels [17:31:14] <mru> Yuvi: I've taken part in some discussions [17:31:27] <mru> and I own the domain name :-) [17:31:37] <elenril> lol [17:32:08] <Yuvi> I could have sworn its sync didn't waste 64 bits like ogg does [17:32:10] <Kovensky> <@mru> and there it excels <-- it's still extremely weak against corruption [17:32:44] <mru> add reliable to the storage requirements [17:32:46] <kierank> they talk about this transOgg format being complete yet it seems development was done in secret [17:33:42] <KotH> kierank: if a group of experts work together, they will end up with a superior format. especially if they can work undisturbed by outside forces [17:33:46] <KotH> kierank: see tarkin [17:33:56] <mru> KotH: yes *experts* [17:34:02] <mru> these are anti-experts [17:34:10] <mru> see tarkin [17:34:36] <KotH> well, i must say, that the tarkin ml was some quite interesting reading [17:34:38] <mru> that list archive makes for some amusing reading [17:34:44] <mru> lol [17:34:50] <Kovensky> KotH: lol [17:34:59] <peloverde> KotH, I suppose that's why AAC has some awful bitstream flaws that I managed to trip all over on my first implementation [17:35:14] <Yuvi> he's completely wrong about overhead for mp4 quick start and needing special muxing to stream matroska... [17:35:42] <KotH> imho we should invite monty to ffcon [17:35:49] <KotH> ohfuck.. [17:35:58] <mru> would he dare? [17:36:01] <KotH> does anyone have the time to organize ffcon? [17:36:04] <kierank> i'd go just to see that [17:36:19] * KotH has adresses for places and can help with contacts [17:36:26] <KotH> but i've no time to do it :( [17:36:30] <kierank> get rathann to organise it at cern ;) [17:36:31] <mru> http://sv.wikipedia.org/wiki/Nyk%C3%B6pings_g%C3%A4stabud [17:36:38] <jai> i assume it will be in EU? [17:36:47] <BBB> nfl: already did [17:36:50] <BBB> nfl: but it's not showing [17:36:54] <BBB> nfl: I don't know why [17:36:58] <KotH> kierank: .ch and especially GE is way too expensive [17:36:58] <BBB> annoys the hell out of me [17:36:59] <Kovensky> if you do it in the US in b4 you get raided by MPAA / RIAA [17:37:16] <jai> lol [17:37:16] <kierank> KotH: true [17:37:25] <kierank> but it's a nice place to visit [17:37:25] <mru> hey, let's ask mpaa for sponsorship :-) [17:37:30] <KotH> mru: what's that? [17:37:36] <mru> now *that* would be a good troll [17:37:46] <kierank> get mpeg-la to sponsor [17:37:49] <jai> FFCon - Brought to you by Jack Valenti? [17:37:52] <mru> KotH: read the english version [17:40:05] <KotH> mru: for this, we'd need the FFarmy [17:40:07] <BastyCDGS> so I'm back [17:40:15] <KotH> BastyCDGS: OH NOES! [17:40:17] <KotH> ;) [17:40:33] <Kovensky> what about the FFairforce [17:40:35] <Kovensky> or airFForce [17:40:39] <BastyCDGS> well you had 2 hours to run away, if you don't use it...:P [17:41:33] <mru> may the FForce be with you [17:41:39] <BBB> I can't find it [17:41:43] <BBB> god damn google [17:41:54] <nfl> BBB: thanks anyway [17:42:06] <BastyCDGS> anything news regarding optimization [17:42:16] <Yuvi> "This is bitchy livejournal material, not technical critique." [17:42:17] <KotH> BastyCDGS: i was at the uni and came back :) [17:42:25] <Kovensky> "index only noticeably improves seek performance in narrow interactive cases, such as HTTP range requests over a satellite or WWAN link. " <-- what about my poor ADSL that is not fast enough to watch youtube on the lowest quality without waiting for it to buffer the whole video before [17:42:28] <BBB> nfl: sorry [17:42:35] <BBB> nfl: can you give an example of other projects that have it? [17:42:53] <mru> Kovensky: according to monty, you do not exist [17:43:06] <jai> why is the homepage on melange even important? [17:43:09] * mru once got this error message: You do not exist. Go away. [17:43:09] <KotH> Kovensky: you dont even have to use such a fringe system [17:43:18] <KotH> Kovensky: just think "mobile phones" [17:43:51] <Kovensky> "there are some new use cases that finally make an index needed" <-- seeking on large video files in hard disk drives are a new use case? [17:43:55] <Kovensky> s/are/is/ [17:43:58] <KotH> mru: deluser `whoami` ? [17:44:02] <nfl> BBB: ascend [17:44:08] <jai> BBB: gentoo has one [17:44:29] <KotH> mru: btw: are you gonna write an answer to taht answer? [17:44:35] <BastyCDGS> mru, yesterday when you added me to voice list I wasn't registered at nickserv, so I'm away again...but I'm now logged in [17:44:40] <BastyCDGS> with nickserv [17:44:58] <mru> let's try again [17:46:19] <BastyCDGS> thanx, I quit channel short and return should work then [17:47:03] <BastyCDGS> hmm lost v again... [17:47:05] <Kovensky> "when latencies are high, latency is in the seek, not the read" <-- it seems that he only considers satellite high-bandwidth connections [17:47:11] <kierank> http://people.xiph.org/~xiphmont/hv40_for_ed/ oh noes xiph hosting patented file formats [17:47:12] <BastyCDGS> why is this? [17:47:19] <Kovensky> are rotating HDDs also considered high latency? =p [17:47:33] <mru> 10ms is medium [17:47:52] <mru> hmm, HDDs have a medium medium latency... [17:50:48] <BastyCDGS> However, a (static) 2D array is faster than the original patch... [17:51:00] <BastyCDGS> do you mean const static in the decodeplane8 function? [17:51:36] <BBB> sloooooooooooooooooooooooooooooooooooow [17:51:39] * BBB kicks google [17:53:14] <Kovensky> KotH: <@Myrsloik> zfs: Mentar is the one "working" on them [17:53:27] <BastyCDGS> please summarize up what is the fastest method for dp8 you found out then? [17:53:31] <astrange> "them"? [17:54:30] <KotH> Kovensky: oh.. damn... [17:54:33] <KotH> Kovensky: ^^' [17:54:48] <KotH> Kovensky: mixed up the M's ^^' [17:59:35] <BBB> jai: can you as the gentoo folks how they did that? [18:03:26] <mru> "When Xiph started out in the early ninties, MPEG was hardly dominant." [18:03:35] <mru> WTFuuuuuuuuck [18:03:52] <mru> in the 90s, there was MPEG and NOTHING ELSE [18:04:12] <BastyCDGS> mru, you forgot IFF-ANIM :D [18:04:26] <BastyCDGS> that existed in the 90s, too. ;) [18:04:32] <mru> just toys [18:04:46] <Kovensky> wasn't there Real and Indeo too? [18:04:51] <mru> also toys [18:04:52] <KotH> asf! [18:05:03] <Kovensky> s/was/were/ [18:05:11] <mru> what was digital broadcast using? [18:05:18] <mru> and are still using [18:05:22] <Kovensky> there was digital broadcast? [18:05:28] <kierank> in the early 90s? [18:05:36] <KotH> hmm... [18:05:38] <kierank> I thought mpeg-2 sd was standardised in '95 or so [18:05:40] <Kovensky> that's mid to late 90s [18:05:48] <Kovensky> at best [18:06:00] <mru> and there is no public record of xiph before 98 [18:06:08] <BastyCDGS> one question about that i = b32 stuff in the 2nd for, I know that it isn't necessary but thought keep it for readibility [18:06:11] <KotH> i remember that cable providers used digital links between the cities in the 90s, but dont remember when and dont know what they used [18:06:37] <KotH> in .ch taht is [18:06:44] <kierank> eurovision used mpeg-2 iirc then [18:07:08] <BastyCDGS> BBB, so should I keep i = 32 or remove it? [18:07:23] <mru> remove it [18:07:28] <BastyCDGS> ok [18:07:30] * KotH remembers the introduction of digital satelite broadcast in mid 90s [18:07:45] <BastyCDGS> and change const uint32_t lut[] = {0x0000000, [18:07:45] <mru> KotH: and I'm sure they didn't use ogg [18:07:50] <BastyCDGS> to static const uint32_t lut[] = {0x0000000, [18:07:52] <KotH> ofc not! [18:07:56] <BastyCDGS> and keep the shifts inside? [18:07:59] <KotH> iirc it was mpeg2 [18:08:02] <BastyCDGS> that's all for new patch? [18:08:02] <KotH> but i'm not sure [18:08:14] <mru> mpeg2 is likely [18:08:21] <KotH> but it was definitly one of teh mpeg family [18:08:48] <kierank> mpeg-2 implementations sucked a lot back then [18:09:06] * KotH remembers the discussion in #mplayerdev about broadcasts and mpeg-ts back then [18:09:27] <kierank> anything involving movement = blockfest [18:09:28] <KotH> hmm.. wait... #mplayerdev was at least 5y later [18:09:39] <mru> lol, monty doesn't even know his own invented terminology [18:09:50] <KotH> i'm starting to mix up dates... looks like i'm getting old [18:10:59] <KotH> ok.. time to go home [18:11:02] <KotH> have a nice evening [18:11:08] <KotH> and blame spaam! [18:11:39] * _av500_ blames ash cloud [18:11:58] <Kovensky> KotH: [18:11:58] <Kovensky> <@Mentar> terrible source [18:11:58] <Kovensky> <@Mentar> kinda hope we'll get a remaster [18:13:00] <BBB> nfl: done [18:13:03] <spaam> KotH: pff i dodnt do anything wrong :D [18:13:35] <nfl> BBB: thanks :) [18:13:56] <BBB> and... I'm on the map also now [18:15:14] <BastyCDGS> hey I think I got it, you mean I should move the static const stuff from my 2nd patch where the static const is outside of any function just inside the loop? [18:16:02] <BastyCDGS> s/loop/function [18:16:34] <jai> BBB: ah, i see you did it [18:16:38] <jai> BBB: sorry, was afk [18:17:15] <BBB> BastyCDGS: yes you can do that [18:17:31] <BBB> BastyCDGS: the compiler output is the same, just the namespace is different [18:17:42] <jai> "Accurate Seeking API"? [18:17:44] <jai> oh well... [18:17:45] <BastyCDGS> ok so I guessed right that your left-out replies to my past questions were indicating that I was guessing wrong ;) [18:17:59] <BBB> nope, you're right [18:18:14] <BBB> I was just not reading all messages [18:18:18] <BastyCDGS> ? but how it can then increase speed by 3%? [18:18:18] <BBB> was a bit busy with other things [18:18:27] <BBB> it's two-dimensional [18:18:37] <BBB> lut[][] instead of lut[] << plane [18:18:47] <BBB> so you don't calculate the entries anymore [18:18:52] <BBB> they are in read-onloy memory [18:18:56] <BBB> static const [18:19:08] <BBB> you just use them directly, without any additional math in the inner loop [18:19:10] <BBB> = faster [18:25:29] <BastyCDGS> did you also check if it's faster the new way with inline or without? [18:25:55] <mru> gcc probably inlines it regardless [18:26:17] <BastyCDGS> well with the original patch it didn't [18:26:28] <mru> because the function was huge [18:29:44] <BastyCDGS> hmm runs lots slower for me [18:29:54] <BastyCDGS> 8,6k instead 6,2k as my origin patch [18:30:13] <BastyCDGS> const unsigned b32 = b & ~3; [18:30:13] <BastyCDGS> // 8 planes * 4-bit mask [18:30:13] <BastyCDGS> static const uint32_t lut[8][16] = {DECODEPLANE8(0), \ [18:30:13] <BastyCDGS> DECODEPLANE8(1), \ [18:30:13] <BastyCDGS> [...] [18:30:30] <BastyCDGS> init_get_bits(&gb, buf, buf_size * 8); [18:30:30] <BastyCDGS> for(i = 0; i < b32; i += 4) { [18:30:30] <BastyCDGS> const uint32_t v = lut[plane][get_bits(&gb, 4)]; [18:30:30] <BastyCDGS> [18:31:57] <BastyCDGS> or did I sth. wrong? [18:31:57] <BastyCDGS> wasn't that the way you meant it be? [18:32:53] <BastyCDGS> or did you mean: [18:33:02] <BastyCDGS> const uint32_t v = decodeplane8_tab[plane][get_bits(&gb, 4)]; [18:36:30] <BastyCDGS> sorry, I'm a bit confused now [18:49:23] <BastyCDGS> submitted a patch [19:19:14] <BastyCDGS> one question what is the proper way to align a data structure within ffmpeg [19:19:27] <BastyCDGS> should I just use gcc's alignment attribute or is there a macro for this? [19:19:46] <BastyCDGS> I mean alignment of a const table [19:19:50] <Dark_Shikari> DECLARE_ALIGNED [19:19:57] <BastyCDGS> thanks [19:21:17] <mru> time to go see those girls... [19:23:45] <BastyCDGS> have fun with them ;) [19:29:40] <BBB> the part where he boasts so much that he is going to see girls, makes it quite obvious how little chance he has to go somewhere with any of them tonight [19:30:01] <BBB> btw mru, tactically speaking a single girl is always easier to corner than a group of girls [19:30:54] <BastyCDGS> well he could train it here ;) [19:30:54] <BastyCDGS> file:///home/basty/Desktop/datingsimulator/default.htm [19:30:56] <BastyCDGS> oops [19:31:00] <Dark_Shikari> lol [19:31:24] <BastyCDGS> http://arianeb.com/dateariane/default.htm [19:31:33] <saintdev> lol [19:32:09] <jai> keeping it on the desktop is pretty handy :) [19:32:27] <BastyCDGS> wtf, what's wrong with here? [19:32:27] <BastyCDGS> DECLARE_ALIGNED(64, static const uint32_t, decodeplane8_tab[8][16]) [19:32:56] <BastyCDGS> yields: /home/basty/src/ffmpeg/libavcodec/iff.c:43: erreur: expected «=», «,», «;», «asm» or «__attribute__» before «decodeplane8_tab» [19:33:49] <Dark_Shikari> first of all, aligning beyond 16 is generally useless [19:33:53] <Dark_Shikari> you can't align to a value greater than the stack alignment [19:34:14] <BastyCDGS> I wanted to align it on cache line boundary and check if that's the cause that the patch is getting such slow for me [19:34:33] <Dark_Shikari> you can't do that in most cases for anything but memaligned data [19:34:47] <Dark_Shikari> and you won't get any penalty for cacheline misalignment as long as you don't use unaligned loads [19:35:29] <BastyCDGS> hmm maybe the bad perfomance for me results in different gcc? [19:36:20] <BastyCDGS> btw, I downloaded the game above because the server crashed often upon playing [19:36:36] <BastyCDGS> and according to murphy always when it got interesting ;) [19:37:33] <BastyCDGS> just a hint, the game is completely uncensored, even at the final end...:P [19:37:55] <BastyCDGS> it's even animated, but won't tell more here, if you want to check it out just play it :D [19:38:31] <BBB> BastyCDGS: DECLARE_ALIGNED(64, static const uint32_t, decodeplane8_tab)[8][16] [19:38:39] <BBB> the sizes go ourside the declare_aligned() macro [19:38:51] <BBB> but I tried that already and it made no difference at all here [19:39:16] <BBB> 64-byte alignment is a huge waste for a 512-byte table btw [19:39:18] <BBB> ust so you know [19:39:34] <BastyCDGS> doesn't work either :( [19:39:36] <BastyCDGS> same error [19:39:44] <BBB> add a ; at the end [19:40:06] <BBB> I just used it and it worked just fine [19:40:14] <BBB> see also libavcodec/vorbis_data.c [19:40:16] <Dark_Shikari> BBB: er, why would it be a waste? [19:40:35] <Dark_Shikari> ok, so in practice it's a waste because gcc is idiotic and doesn't know how to pack rodata properly [19:40:41] <BBB> right [19:40:48] <BBB> in theorry you could rearrange ro [19:40:49] <Dark_Shikari> in before gcc devs complain that bin-packing is NP-complete [19:40:52] <BBB> but gcc will just zero-pad it [19:41:58] <BastyCDGS> still doesn't work [19:42:08] <BastyCDGS> same error, gcc 4.2.4 bug? [19:43:16] <BastyCDGS> DECLARE_ALIGNED(16, static const uint32_t, decodeplane8_tab)[8][16] = {DECODEPLANE8(0), [19:43:17] <BastyCDGS> DECODEPLANE8(1), [19:43:20] <BastyCDGS> ... [19:43:21] <Yuvi> if it's global data, it's more likely to be an as/ld bug [19:43:42] <Dark_Shikari> wtf is the [8][16] doing outside of the ) [19:43:59] <BBB> that's how vorbis_data does it [19:44:15] <Yuvi> because of the #pragma align iirc [19:44:18] <BBB> DECLARE_ALIGNED(16, static const float, vwin64)[32] = { [19:44:27] <BastyCDGS> I took this as base [19:44:49] <BBB> sorry, that's all I know [19:44:54] <BastyCDGS> doesn't it work with 2D arrays? [19:44:55] <BBB> if that doesn't work then I don't know [19:44:57] <BBB> it does [19:44:59] <BBB> I tested it [19:45:19] <BastyCDGS> maybe you can use only basic data types? [19:45:24] <BBB> no [19:45:27] <BBB> I used uint32_t [19:45:48] <BBB> anyway, it's not gonna help, I tested it :) [19:45:51] <BastyCDGS> then it's clearly a bug [19:46:22] <BBB> it works for vorbis_data.c right? [19:46:27] <BastyCDGS> yes it works [19:46:27] <BBB> looks more like a typo somewhere or so [19:46:46] <BBB> what is DECODEPLANE8 defined as? [19:47:14] <BastyCDGS> same as my latest patch [20:00:12] <BastyCDGS> new patch submitted to ml [20:08:47] <BastyCDGS> BBB: what about the 24bpp stuff? there wasn't a review yet [20:08:54] <BBB> one thing at a time [20:09:46] <BastyCDGS> well, if you want me fixing at least most critical stuff now, then please do now, since I want to go bed in some minutes [20:09:53] <BastyCDGS> I'm horribly tired, didn't sleep last night [20:10:57] <BastyCDGS> another thing I want to mention though, I discussed today with my chief at university if I can do GSoC while being at work [20:11:07] <BastyCDGS> and combine that with my bachelor exam [20:11:28] <BastyCDGS> well, he said, it could be something to do what we do at work (that means numeric library stuff) [20:11:53] <BastyCDGS> stuff like interpolation, fft, etc. can be probably very well be included with my mod task [20:12:38] <BastyCDGS> (don't confuse the bachelor exam with the education exams I have on 12th may until 21th) [20:13:00] <BastyCDGS> I have to finish bachelor exam until 15th august [20:27:52] <BBB> michael's 4-byte dst alignment suggestion is quite good, check that [20:36:09] <bcoudurier> hi guys [20:36:36] <BBB> hello bcoudurier's onjoin script [20:37:37] <bcoudurier> hello BBB [20:39:15] <BBB> :-p [20:50:36] <BBB> BastyCDGS: ca you test which method is fastest for 32bpp also and re-send the best patch for that? [20:50:56] <BastyCDGS> of course, but not tomorrow [20:51:03] <BastyCDGS> s/tomorrow/today [20:51:34] <BastyCDGS> btw, just figured out that (buf_size * 8) + bps - 1 [20:51:45] <BastyCDGS> + bps - 1 can be removed, the one test image remained the same [22:10:07] <twnqx> omg [22:10:14] <twnqx> sometimes it's so easy... [22:10:19] <lu_zero> mru: monty loves you, isn't it? [22:10:40] <twnqx> randomly browse the vendor's webpage, find the native 64bit of the app you try to make work on 64bit for free DL [22:11:07] <twnqx> add some experimental, slightly patched driver from another vendor, happyness [22:11:34] <iive> twnqx: sounds like windows. [22:12:08] <twnqx> or the nightmare of commercial software on linux. [22:15:04] <twnqx> funnily i received an email from the driver vendor, stating their driver works only up to 2.6.29 [22:15:35] <twnqx> i did not manage to compile an unpatched driver against that, but a slightly patched (change of include locations) works with 2.6.33 [23:59:43] <iive> there is something I don't understand in monty's refutal. He tries to refute mru 50 seeks in 10GB file, and he ends up with 17459 seeks... Even if real seeks are 3.5 or 4 times less, it is still HUGE number.

1 0

IRC log for 2010-04-26
by irc＠mansr.com 27 Apr '10

27 Apr '10

[09:17:06] <KotH> http://xkcd.com/732/ [09:22:32] <kshishkov> yep, good for HDTV advertising ;) [09:22:53] <kshishkov> still, http://xkcd.com/730/ touched something in my soul too [09:23:53] <KotH> kshishkov: do you know electronics? [09:24:00] <av500> KotH: HD is about buying *big* TVs, never mind the resolution [09:24:02] <pJok> god middag, kshishkov :) [09:24:20] <kshishkov> god dag, pJok [09:24:59] <kshishkov> KotH: yep, a bit. Not to mention that our schematics slightly differ since they were stolen fron DIN looong time ago [09:25:50] <KotH> eh.. [09:25:54] <KotH> kshishkov: dont worry about that [09:26:04] <KotH> kshishkov: europe uses a mix between din and us symbols [09:26:13] <KotH> kshishkov: though mostly din [09:26:32] <kshishkov> well, resistors are drawn like rectangles here [09:26:58] <KotH> there is no other way to draw resistors ;-) [09:27:05] <av500> here too [09:27:31] <kshishkov> americans use wiggly lines [09:27:38] <av500> americans... [09:27:57] <kshishkov> av500: "here too" means you actually know about DIN [09:28:16] <KotH> kshishkov: you know what din stands for? ;) [09:28:22] <av500> I din nothing wrong [09:28:53] <kshishkov> KotH: av500_current_country Institute fuer Nationalstandarten oder etwas [09:29:07] <av500> industry norm [09:29:49] <KotH> s/y/ie/ ;) [09:30:12] <av500> iees! [09:30:58] <KotH> da war kein g hinten drann! [09:31:31] <av500> achso [09:34:15] <kshishkov> hmm, wikipedia says it's "Deutsches Institut fuer Normung" and "industy norm" is wrong explanation [09:35:00] <av500> kshishkov: bah, wikipedia :) [09:35:05] <KotH> who says taht wikipedia is right? [09:35:29] <kshishkov> wikipedia does [09:35:58] <av500> kshishkov: quick survey among 3 coworkers yield "... Industrie Norm" :) [09:35:58] <kshishkov> IIRC some Ukrainian laws are like that too - they have higher priority because they say so [09:36:09] <av500> kshishkov: but I guess wiki is still right [09:36:23] <KotH> av500: cow-orkers? [09:36:24] <KotH> ;) [09:37:55] <av500> yes, we milk orcs [09:37:56] <janneg> http://de.wikipedia.org/wiki/Din says formerly „Deutsche Industrie-Norm“, today DIN-Norm [09:38:28] <KotH> deutsche industrie norm norm? [09:38:32] <KotH> sounds wrong [09:39:04] <av500> no, deutsches inst. für Normung norm [09:39:08] <janneg> deutsches institut für normung norm still sounds wrong [09:39:21] <kshishkov> not at all [09:39:52] <av500> hmm, maybe kshishkov should be german language maintainer too [09:39:59] <av500> he knows more than me about it :) [09:40:01] <janneg> it sounds very much like LCD display [09:43:13] <kshishkov> av500: looks like I manage without German lanuage knowledge even here [09:44:45] <av500> I trust you'll do fine :) [10:12:59] <Kovensky> we saw a bit of electronics @ HS [10:13:19] <Kovensky> I was like lolconfused because the symbols used were completely different from US symbols (which I had studied before on my own) [10:13:50] <Kovensky> well, s/electronics/electric circuits/ [10:18:51] * KotH thinks that for all but logic symbols, the german ones are easier [10:19:22] <KotH> for logic the usian symbols are more clear... unless you have to draw a lot of or/xor gates :) [10:36:26] <siretart> KotH: can you disable the whitespace enforcment hook for mplayer's svn branches (i.e. not trunk)? [10:37:00] <KotH> probably [10:37:02] <KotH> why? [10:37:23] <siretart> KotH: I wanted to backport some fixes from trunk to rc3, but the commit hook complained about trailing whitespace [10:37:39] <KotH> why dont you remove those whitespaces then ? [10:37:57] <siretart> that would be an unrelated change to the file [10:38:14] <KotH> and how come files in trunk contain white spaces? [10:38:20] <KotH> er.. trailing whitespaces [10:38:35] <siretart> I don't backport the file. I backport a change [10:38:45] <siretart> the whitespace cleanup is not part of the change I want to backport [10:39:20] <KotH> why not do it anyways? [10:39:36] <KotH> there is no reason to keep trainling whitespace in c code [10:40:04] <siretart> main reason: fear of an angry diego ;-) [10:40:31] * KotH thinks that entering trainling whitespace would anger him even mroe [10:40:34] <KotH> more* [10:40:58] <siretart> it does not enter, it is already in the file [10:41:14] <KotH> huh? [10:41:33] <KotH> you mean, there is a file that diego missed? [10:41:53] <siretart> of course, he applied the restriction to the whole repo, but only cleaned up trunk [10:42:16] <KotH> ^^' [10:42:46] <KotH> then the correct thing to do is, backport the whitespace fix first, then beat diego, then backport the real fix [10:43:02] <siretart> I see [10:43:05] <av500> git-beat-diego? [10:43:18] <siretart> perhaps I should switch the first two items [11:08:10] <twnqx> hi guys, would you happen to know if mplayer is using ffmpeg for rtsp, or does it have its own implementation? [11:10:48] <twnqx> ok, seems it uses librtsp... [11:11:48] <wbs> which librtsp is that, btw? [11:12:14] <twnqx> ./mplayer/stream/librtsp/rtsp_session.c [11:12:20] <wbs> ah [11:36:27] <Compn> mplayer has its own rtsp (real media) code [11:36:49] <Compn> and it uses live555 for rtsp:// (anything else except .rm) [11:37:03] <Compn> or you can use mplayer ffmpeg://rtsp:// if you want to use ffmpegs rtsp :) [11:37:20] <wbs> ah, ok :-) [11:37:33] <wbs> I tried live555 for some stuff earlier, but wasn't really too fond of it [11:37:41] <Compn> why twnqx is asking in #ffmpeg-devel i dunno [11:39:18] <Compn> live555 doesnt support the X-perimental streams [11:39:34] <Compn> which is some quicktime streams, all wmv/asf streams, and some random others [11:40:18] <twnqx> because i wasn't sure if it uses libavf for that, since i remember some recent work on ffmpeg's rtsp support [11:46:01] <Compn> rtsp://stream.diffusion.ens.fr/2008_10_03_albarede.mov [11:46:09] <Compn> does that stream work in ffplay? it crashes here ;\ [11:46:48] <twnqx> my ffplay claims it doesn't find the file [11:47:04] <twnqx> rtsp://stream.diffusion.ens.fr/2008_10_03_albarede.mov: No such file or directory [11:47:14] <Compn> you dont have network support? :\ [11:47:14] <twnqx> gah [11:47:18] <twnqx> --disable-network [11:47:21] <twnqx> :( [11:47:56] <wbs> Compn: hmm, doesn't seem to crash here, do you have the latest version? [11:48:04] <Compn> wbs : no, i do not [11:48:15] <wbs> I think BBB fixed something some time ago that could lead to crashes if it was fed an unsupported format [11:48:30] <Compn> wbs : does that url play ? [11:49:12] <wbs> nope, it doesn't... i think that's stuff that j0sh will implement in gsoc, though [11:49:35] <wbs> is that url permanently available? that would be a good test case for gsoc :-) [11:49:51] <Compn> i dunno [11:50:07] <Compn> its been in mplayer bugzilla since 2009-06 [11:52:14] <ohsix> doesn't crash here, with debug prints the following then hangs, after ^c it sez could not find codec parameters; [rtsp @ 0x141b4f0]hello state=0 [11:52:44] <Compn> http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1486 [11:52:48] <wbs> ah, I've got access to other samples with similar content already [11:52:56] <wbs> but yes, that's part of j0sh's soc proposal [11:53:13] <Compn> wbs : http://wiki.multimedia.cx/index.php?title=RTSP [11:53:18] <Compn> theres a bunch of rtsp samples for testing [11:53:30] <Compn> i think BBB got a few of them working (at least with gstreamer) :) [11:53:50] <ohsix> that sounds like a challenge [11:54:14] <Compn> wbs : if you have more sample streams, put them on the wiki (or msg me, and i'll put them up) so other projects can test [11:54:35] <ohsix> it works with gstreamer [11:54:54] <wbs> Compn: the ones I've got aren't available on any public server, but available in the darwin streaming server distribution [11:54:58] <Compn> ah [11:55:10] <Compn> well those are some 'real-world' samples for you and josh :) [11:55:15] <wbs> yeah :-) [11:55:19] <ohsix> just played it in totem :[ [11:55:41] <Compn> hehehe [11:59:36] <KotH> ohsix: YOU HAVE BEEN TAINTED! [11:59:38] <KotH> ;) [12:00:05] <ohsix> too bad ffmpeg running out of free frames keeps me from my mkvs [12:00:47] <Kovensky> o_O [12:00:55] <Kovensky> there are paid ffmpeg frames? [12:00:58] * Kovensky ducks [12:01:32] <ohsix> theres a list of unused frames that is finite in size [12:01:45] <ohsix> so if you queue too many in your renderer they run out [12:02:56] <Kovensky> isn't that a renderer problem rather than a libavcodec one [12:03:20] <kshishkov> ohsix, so you are a very greedy man graabing all possible frames at once [12:03:28] <twnqx> Stream #0.0: Video: mpeg4, yuv420p, 176x144 [PAR 1:1 DAR 11:9], 12.50 tbr, 90k tbn, 12.50 tbc [12:03:28] <twnqx> Stream #0.1: Audio: 0x0000, 8000 Hz, 1 channels [12:03:38] <twnqx> wouldn't one expect ffplay to open a window at some point, then? :X [12:03:55] <ohsix> bursty saves power :> [12:03:56] <kshishkov> for such a small video? unlikely [12:04:18] <twnqx> heh [12:04:22] <twnqx> it's for mobile tv [12:04:28] <ohsix> Kovensky: that its static and not knowable at runtime its a problen [12:04:34] <twnqx> also, the audio doesn't work either [12:06:44] <wbs> do normal video codecs like mpeg4 or h264 work with anything else than 4:2:0-video? [12:06:56] <wbs> on some platforms, there are encoders that accept 4:2:2 as input [12:07:07] <Kovensky> H.264 supports 4:4:4 on the lossless profile [12:07:13] <Kovensky> don't know about others [12:07:18] <Kovensky> (or other profiles) [12:07:27] <wbs> ok [12:07:41] <wbs> well, I guess I'll find out when I get it all hooked together [12:09:44] <lu_zero> hi [12:10:02] <Kovensky> x264 doesn't produce 4:2:2 or 4:4:4 video yet though (it's a GSoC task though) [12:11:11] <kierank> there is also not a decoder apart from the jm [12:11:23] <kierank> s/a/a free [12:11:34] <wbs> for h264 with 4:2:2? [12:12:00] <kierank> yes for h264 w/ 4:2:2 and 4:4:4 [12:14:22] <wbs> ok [12:27:06] <lu_zero> sigh [12:27:16] <lu_zero> dhcpcd seems to have a _bit_ of problems [12:29:31] <kshishkov> use somthing else, for example static IPs then [12:30:28] <ohsix> you cab flag it with -S too [12:31:52] <mru> what's the problem with dhcpcd? [13:12:21] <hyc> hm, I just noticed that ffmpeg has an SWF decoder [13:12:28] <hyc> and it doesn't support compressed SWFs [13:12:44] <hyc> it just so happens that librtmp *does* support compressed SWFs [13:12:47] <kshishkov> we have a tool to decompress them though [13:13:16] <JEEBsv> wait, _decoding_ of swf? Isn't that more like scripts to be rendered? [13:13:30] <hyc> I guess it's a demux [13:13:32] <JEEBsv> ah [13:13:38] <JEEBsv> yeah, video-in-swf [13:14:36] <hyc> well, all it takes to do it is zlib, and ffmpeg already has zlib dependencies [13:14:48] <hyc> matroskadec.c and mov.c [13:15:30] <kshishkov> here it's whole file compressed, may be quite different situation [13:15:58] <hyc> no, a compressed SWF has a header that is not compressed [13:16:11] <kshishkov> 8 bytes [13:16:15] <hyc> yep [13:16:24] <hyc> it's trivial to use zlib here [13:16:50] <kshishkov> IIRC, mov/mkv have rather small chunks compressed while cws is a whole file compressed at once [13:17:15] <hyc> excluding those first 8 bytes, yes. [13:17:33] <hyc> but zlib can operate on a buffer-at-atime [13:17:46] <mru> tools/cws2fws.c [13:18:43] <hyc> so, no need for a patch for this then? [13:19:01] <wbs> if you're able to do it neatly I guess it's most welcome [13:19:41] <kshishkov> oh, that's easy - implement zlib:// protocol and use it as an intermediate level for reading ;) [13:19:55] <hyc> it's probably no more than 20 lines of additional code. haven't written it yet of course, but judging from how long it took to add to librtmp. [13:20:11] <av500> hyc: how do you seek in compressed SWF? [13:20:16] <av500> :) [13:20:33] <hyc> doh.... [13:20:50] <hyc> hah, that was a trick question [13:20:56] <hyc> swfdec.c has no seek implemented [13:21:04] <av500> doh [13:24:03] <hyc> but still a good question. I'm not gonna touch it. [13:34:50] <BBB> mornin' [13:35:01] <av500> 'jour [13:37:08] <CIA-7> ffmpeg: rbultje * r22965 /trunk/libavutil/common.h: [13:37:08] <CIA-7> ffmpeg: Fix broken 32-bit clipping, and write numbers in hex instead of decimal so [13:37:08] <CIA-7> ffmpeg: they are easier to understand. Also give the add a 'u' postfix to silence [13:37:08] <CIA-7> ffmpeg: a pre-c99 compiler warning. [13:43:38] <BastyCDGS> greetz to all [15:11:22] <superdump> want a new video format with samples? http://www.3xlogic.com/aztech [15:13:17] <kshishkov> my BS detector gives some warnings [15:13:34] <kierank> the things it says about h.264 make no sense [15:14:03] <kshishkov> exactly [15:15:01] <superdump> maybe shitty h.264 encoders don't do well with low framerates [15:16:19] <superdump> because they don't do well with anything [15:17:00] <kshishkov> by definition [15:17:56] * KotH defines kshishkov as 3.1415 [15:18:46] <kshishkov> KotH, I can now visit Switzerland [15:19:27] <janneg> approximations of PI don't need a visum? [15:19:48] <av500> "When you record at less than 30fps with H.264 you end up with a lot of overhead in your video due to this flaw..." [15:19:50] <av500> wtf? [15:20:24] <KotH> janneg: he'll still need a visum, but people will imediatly see that he is country-challanged [15:21:02] <kshishkov> av500: you HD-video will be full of NALs [15:23:04] <av500> "omg, it is full of NALs" [15:23:10] <KotH> NALs? not FNORDs? [15:23:26] <kshishkov> KotH: 3/5 of it [15:52:55] <BastyCDGS> yeah, was able to speedup 24bpp plane decoding by over 200% [15:53:04] <BastyCDGS> patch just submitted to ml [15:54:50] <jai> if only this was for h.264 ... ;) [15:55:35] <kshishkov> well, just wait for 24bpp support in H.264 ;) [15:55:41] <BastyCDGS> lol [15:55:58] <jai> i meant the speedup [15:55:58] <BastyCDGS> I required 4 lut's for that [15:56:27] <BastyCDGS> interestingly, the decodeplane8 is much faster with inline statement while it's the opposite with decodeplane32 [15:58:35] <BastyCDGS> btw [15:58:59] <BastyCDGS> is there a way in ffmpeg to determine if CPU is 64 independent of architecture instead of doing a if (sizeof(void*) >= 8) ? [15:59:22] <BastyCDGS> I want to optimize decodeplane8 if the CPU is 64-bit by doing unroll of 8 instead of 4 [15:59:34] <Dark_Shikari> hmm. in x264 we do if(WORD_SIZE == 8) [15:59:41] <Dark_Shikari> .... of course WORD_SIZE is #defined to sizeof(void*) [15:59:43] <BastyCDGS> I search sth. like #ifdef HAVE_64BIT_CPU [16:00:01] <BastyCDGS> does the compiler optimize such things out? [16:00:09] <BastyCDGS> you should not do == 8 [16:00:11] <BastyCDGS> do a >= 8 [16:00:21] <BastyCDGS> because it won't use 64-bit then on 128-bit CPUs ;) [16:00:56] <BastyCDGS> this is far into the future of course, but someday this will happen they'll appear [16:00:56] <Dark_Shikari> yes, 128-bit cpus made out of unicorn dust [16:02:07] <BastyCDGS> ahh now I know why unicorns died out, they killed them to make CPUs out of them :D [16:02:31] <JEEBsv> that sounds very probable [16:02:38] <BastyCDGS> hehe [16:02:57] <BastyCDGS> btw, the guys of you having a 64 bit CPU could you check my latest patch using AV_64WNA? [16:03:03] <BastyCDGS> this is slower for my 32-bit CPU [16:03:10] <kshishkov> there are always 1024-bit CPUs made from marketing dust [16:03:12] <BastyCDGS> but maybe this differs to a 64-bit CPU [16:03:29] <Dark_Shikari> BastyCDGS: get yourself a 64-bit cpu to bench on [16:03:36] <Dark_Shikari> yes this may mean getting an ssh account somewhere [16:03:53] <BastyCDGS> good you're mentioning this...I could do this at our university cluster [16:04:09] <BBB> 200% is at least worth it [16:04:13] <BBB> unlike the 1-2% of yesterday [16:04:43] <BastyCDGS> for the 8bpp decoder it's even more than this, almost 400% ;) [16:05:28] <BastyCDGS> or even, is there a better way writing this in ffmpeg? [16:05:29] <BastyCDGS> AV_WN64A(dst+i, AV_RN64A(dst+i) | ((uint64_t) lut3[mask] << 32) | (uint64_t) lut2[mask]); [16:05:40] <BastyCDGS> AV_WN64A(dst+i+2, AV_RN64A(dst+i+2) | ((uint64_t) lut1[mask] << 32) | (uint64_t) lut0[mask]); [16:06:04] <BastyCDGS> this slows down on 32-bit [16:06:08] <Dark_Shikari> of course it does [16:06:12] <Dark_Shikari> gcc sucks ass with 64-bit math on 32-bit [16:06:12] <BastyCDGS> as opposed to: [16:06:18] <BastyCDGS> dst[i] |= lut3[mask]; [16:06:18] <BastyCDGS> dst[i+1] |= lut2[mask]; [16:06:18] <BastyCDGS> dst[i+2] |= lut1[mask]; [16:06:18] <BastyCDGS> dst[i+3] |= lut0[mask]; [16:06:28] <Dark_Shikari> Also, whether or not that code is faster is going to heavily depend on the ALU of the particular CPU [16:06:46] <Dark_Shikari> if the ALU has much faster arith than load/store, it will help [16:06:51] <Dark_Shikari> if it has slower arith, it will hurt [16:07:14] <Dark_Shikari> which means such optimizations are generally a bit dubious as their effect varies wildly depending on the cpu and the phase of the moon [16:07:28] <BastyCDGS> BBB, what about the patches from yesterday...I think they'll go to mainline repo? [16:07:43] <BastyCDGS> well, my CPU is a Athlon XP+ 2100 [16:08:01] <BBB> I'll getthem in [16:08:04] <BBB> busy with something else [16:08:11] <BBB> mru basically says the const does nothing [16:08:15] <BBB> which is my impression also [16:08:15] <BBB> t [16:08:15] <BBB> he [16:08:16] <BBB> c [16:08:16] <BBB> om [16:08:16] <BBB> p [16:08:17] <BBB> [16:08:18] <BBB> ? [16:08:26] * BBB kicks IRC client [16:08:47] <jai> BBB: which one? [16:08:52] <BBB> I'd suggest to remove it, still, the compiler won't do anything with it, unless you can actually show me that the compiler output (disassembly) changes as a result [16:09:09] <BBB> which I find hard to believe [16:09:21] <BBB> jai: his const b = ...bufsize/bps...; [16:09:44] <jai> right [16:09:57] <BastyCDGS> there isn't a division there anymore ;) [16:10:46] <BBB> uhm, well, it's easier to build your patches on previous patches if you want to get patches in [16:10:53] <BBB> now I have to review it back from the beginning [16:11:04] <BastyCDGS> if you don't dare me, I'ld like to keep it, since I want to prevent that someone changes b after initialization... [16:11:11] <BastyCDGS> this will break the decoding seriously [16:11:32] <BastyCDGS> it's a new patch not touching the other one [16:11:53] <BBB> I get that [16:11:57] <BBB> but nobody will ever change it [16:12:02] <BBB> seriously, we're quite good programmers :) [16:12:14] <BBB> we understand that if you change a buffer halfway the printf(), things go bad [16:12:16] <BBB> we get that :) [16:12:50] <BBB> so again, show me that the disassembly changes as a result of the const (in a postive way), and it's ok [16:12:55] <BastyCDGS> also don't wonder why I did remove that DECLARE_PLANE stuff...they're really two separate functions now [16:12:58] <BBB> otherwise it's six characters of wasted space in the source code [16:13:01] <BastyCDGS> not using that #define hack anymore [16:13:10] <BBB> that's probably ok [16:13:13] <BBB> but separate patch [16:13:22] <BastyCDGS> this was necessary because the new code differs to much, also the fact the one being inlined and the other not [16:13:23] <BBB> you shouldn't mix 20 things in a patch [16:13:26] <BBB> they're quite big already [16:14:00] <BastyCDGS> so you mean, I should do one patch, which just removes #define stuff and keeps everything else as it was and then adding my high-optimization stuff? [16:14:13] <BBB> first the two patches you submitted yesterday [16:14:18] <BBB> then a new patch for the remove-#define [16:14:18] <BastyCDGS> also I updated the function parameter descriptions should this be done in a separate patch also? [16:14:25] <BBB> and then another one for whatever new opts you came up with today [16:14:38] <BBB> the two yesterday should be kept as-is, so I can apply them as-is [16:14:44] <BBB> eptying a patch-queue is important [16:14:48] <BBB> emptying* [16:15:08] <BastyCDGS> well the today decodeplane32 patch also includes my yesterday decodeplane8 patch, since I changed both [16:15:53] <BastyCDGS> I'll summarize up now: [16:16:15] <BastyCDGS> first I do a patch which separates decodeplane##suffix stuff into decodeplane8 and decodeplane32 based on the original git code [16:16:36] <BastyCDGS> then I'll do a patch for updating the function descriptions [16:16:59] <BastyCDGS> then I'll apply a patch which optimizes decodeplane8 [16:17:08] <BastyCDGS> and finally one with optimizes decodeplane32 [16:17:15] <BastyCDGS> any disagreements about this? [16:17:21] <BBB> that sounds good [16:17:28] <BBB> so I can apply yesterday's patches? [16:17:59] <BastyCDGS> yes, because they only work with my micro-op patch right now... [16:18:19] <BBB> ok [16:18:25] <iive> BastyCDGS: may I ask you something. I assume you are working on some kind of decoder. Does this decoder support video encodings of different bit depths. [16:18:26] <BBB> give me until this afternoon and I'll do it [16:18:48] <iive> or your decoder can output same bitstream decoded into different bitdepths? [16:18:50] <BastyCDGS> yes anything from 1-24bpp [16:18:59] <BastyCDGS> IFF-ILBM [16:19:05] <BastyCDGS> HAM6/8 support will be added very soon ;) [16:19:14] <BastyCDGS> both will also decode to 24bpp [16:19:41] <BastyCDGS> iive the decoder can output to 8bpp and 32bpp right now [16:19:47] <BastyCDGS> input is 1-24bpp [16:20:12] <BastyCDGS> but I was thinking of adding 16bpp support too...or isn't that necessary? [16:20:22] <BastyCDGS> (maybe 15bpp also) [16:20:23] <iive> i believe that there is notion that the decoder should decode into the native format, and let swscale handle the rest [16:20:39] <BastyCDGS> both 8bpp and 32bpp are ffmpeg's native ones ;) [16:20:51] <iive> bitstream native [16:21:14] <BastyCDGS> but separating the 2 decoders gives a 200-300% speed up to 8bpp as opposed to 32bpp [16:21:47] <BastyCDGS> iive, does swscale have a planar2chunky handler? [16:21:49] <iive> if it is palette... you can decode the palette into 32bpp, it won't be the native format. [16:22:09] <BastyCDGS> there's palette also, and palette is decoded to 32bpp [16:22:35] <iive> chunky? [16:23:08] <BastyCDGS> read this: [16:23:10] <BastyCDGS> http://amiga.nvg.org/amiga/amigafaq/AmigaFAQ_16.html [16:23:44] <iive> bitplanes? [16:24:19] <BastyCDGS> suppose we have a image with 3 bitplanes: [16:25:30] <BastyCDGS> for each set bit in the plane [16:25:59] <BastyCDGS> do a chunky |= (1 << plane); // plane = plane number from 0..2 [16:27:04] <av500> so chunky = "normal", bitplane = err, "bizzare" :) [16:27:23] <BastyCDGS> av500, you can explain this way hehe [16:27:26] <kshishkov> av500: bitplane = "not used in moder h/w" [16:27:30] <kshishkov> *modern [16:27:32] <BastyCDGS> chunky = VGA type pixel mode [16:27:55] <kshishkov> BTW, don't forget to download some stull illegally, it's the day [16:27:57] <Dark_Shikari> http://www.confessionsofacheapskate.com/wp-content/uploads/2010/01/campbell… [16:27:59] <kshishkov> *stuff [16:27:59] <iive> bitplane = cga/ega [16:28:01] <Dark_Shikari> chunky? [16:28:26] <av500> kshishkov: I will not download any "stuhl" [16:28:28] <BastyCDGS> bitplanes can be very effective though depending on what you're doing, thanks to bitplanes the amiga was able to do smoother parallax scrolling than a pentium 1 with a SVGA card...even the amiga just had a CPU with 7MHz [16:28:50] <kshishkov> av500: download something pirated anyway, it's the day [16:28:59] <av500> I do every day [16:29:07] <av500> what makes this one special? [16:29:09] <kshishkov> download more then [16:29:18] <av500> gee, ok ok [16:29:24] <kshishkov> it's World Intellectual Property Day [16:29:38] <iive> BastyCDGS: not really I've always thought that these scrolling games are done by stride(linesize) and startoffset tricks. [16:29:41] <BastyCDGS> WIPD? ok then I'll download the whole pirate bay archive :D [16:30:23] <BastyCDGS> http://en.wikipedia.org/wiki/Parallax_scrolling [16:30:42] <Dark_Shikari> oh shit, WIPD [16:30:49] <Dark_Shikari> well ok, so I have a pirated game open [16:30:54] <Dark_Shikari> and a pirated image editor open [16:31:02] <Dark_Shikari> and a music player open containing pirated songs [16:31:07] <av500> you pirated gimp? [16:31:11] <BastyCDGS> lol [16:31:13] <Dark_Shikari> maybe I can open pirated source code in notepad++ [16:31:23] <BastyCDGS> I just pirated linux [16:31:29] <Dark_Shikari> YARRRRRRR [16:31:40] <iive> BastyCDGS: aha, so unlike bitplanes, these are allowed to overlap. [16:31:56] <BastyCDGS> what's allowed to overlap? [16:32:41] <iive> i mean, if we have B&W (1 bit) and we have 4 planes, if any of the planes have 1, there would be visible 1 [16:33:19] <iive> unlike the bitplanes, where the presense of 1 in one plane would give different result than presence of 1 in another plane (aka 0001 vs 0010) [16:33:20] <av500> BastyCDGS: how does bitplanes help with parallax scrolling? [16:33:30] <BastyCDGS> if plane 0 has set bit we have color index 1, if plane 1 is alone set we have color index 2, if plane 2 is alone set we have color index 4, etc. [16:33:48] <BastyCDGS> if plane 0+1 are set, we have color index = 3; [16:34:00] <av500> right [16:34:42] <BastyCDGS> av500, I don't know this really, I just read 10 years ago in a scene magazine about that where this was claimed by a TRSi member [16:34:45] <iive> so, 4 planes form 4 bit palette. [16:34:50] <BastyCDGS> and I guess these guys know what they do ;) [16:34:50] <av500> iive: yes [16:35:03] <av500> its just 4 bits left to right or front to back [16:35:13] <BastyCDGS> iive, exactly [16:35:21] <BastyCDGS> n planes form 1 << n palette ;) [16:35:37] <iive> how many planes do you have max? [16:35:48] <av500> 0 is ash_cloud is set [16:35:50] <av500> if [16:35:57] <BastyCDGS> in my decoder? there is support upto 24bpp [16:36:12] <iive> 2^24 palette? [16:36:15] <BastyCDGS> yes [16:36:47] * iive checks if his PC have enough memory for the whole palette. [16:36:57] <kshishkov> 2^24 is mere 16Mb [16:37:14] <av500> iive: you could cleverly create a natural pallette that maps to 24bit RGB :) [16:37:16] <BastyCDGS> using HAM you can get upto 4096 colors to be displayed at once using 6bpp, and 262144 colors using 8bpp [16:37:31] <BBB> spyfeng: thanks :) [16:38:32] <iive> yep 3*16mb, i think the video card have enough ram for it. [16:39:10] <BastyCDGS> BBB, one question for the patches...as already said I have commented out two WN64A lines...should I keep or remove them in the patch? [16:39:22] <BBB> remove, for now [16:39:26] <BastyCDGS> ok [16:39:29] <BBB> we don't want disabled code in here [16:39:32] <BBB> it's generally messy [16:42:00] <saintdev> <BastyCDGS> I just pirated linux <-- I just downloaded Ubuntu off the pirate bay. Where is the crack???? [16:42:44] <BastyCDGS> I found it somewhere on cracks.am [16:42:46] <iive> BastyCDGS: so my questions go on. I can imagine 8 bit palette lookup table, but how do you handle bigger index tables. [16:42:47] <BastyCDGS> :D [16:42:57] <iive> i suspect that HAM have something to do with it. [16:43:20] <av500> HAM is delta compression basically [16:43:21] <BastyCDGS> http://en.wikipedia.org/wiki/Hold_And_Modify [16:43:28] <BastyCDGS> this is a very good explanation of HAM [16:43:32] <BastyCDGS> better than I could describe it [16:43:33] <av500> hold last pixel data and change only part of it [16:45:28] <saintdev> i wonder what results do show up for ubuntu on cracks.am, lol [16:46:27] <saintdev> hmmm, only two hits for mainactor [16:46:53] <kshishkov> saintdev: probably full iso and download via usenext [16:47:25] <saintdev> kshishkov: huh? [16:47:53] <kshishkov> saintdev: that's what usually shown on most of crack search sites [16:48:01] <BastyCDGS> lol [16:48:08] <saintdev> oh yeah, lol [16:48:15] <BastyCDGS> yes can't see that usenext stuff anymore [16:48:22] <iive> BastyCDGS: if i grokked the summary correctly, the palette is giving not the color itself, but the delta (difference) of the color, compared the the previous pixel. [16:48:28] <saintdev> i've got a blind spot in my vision for those :P [16:49:59] <BastyCDGS> BBB, just another question, should I change the function prototypes also when doing the separation patch for decodeplane8/32? [16:50:08] <BBB> ? [16:50:10] <BastyCDGS> i.e. in one patch? I have to change these lines anyway [16:50:13] <BBB> you mean void->uint8/32? [16:50:16] <BBB> sure, why not [16:50:20] <BastyCDGS> for example and that const stuff [16:50:27] <BastyCDGS> +unsigned [16:50:51] <BastyCDGS> and already making decodeplane8 inline [16:51:12] <BastyCDGS> the other one is MUCH slower with inline keyword, while dp8 ist MUCH faster with inline keyword [16:52:23] <av500> iive: there are 16 pallette entries, then from them you update R,G or B component directly per pixel [16:53:01] <BastyCDGS> BBB, with unsigned I mean the function declaration, not the body... [16:53:12] <iive> so you still have 4bit palette, but it works in delta mode. [16:53:42] <av500> hmm, I think you have RGB444, but you can only change 4bit per pixel [16:53:46] <BastyCDGS> but if you like I can also integrate int i, b => unsigned i, b [16:54:01] <BastyCDGS> but I think you'd prefer that to be in another patch (latter one) [16:54:06] <BBB> BastyCDGS: split it all as much as possible [16:54:13] <BBB> keep the original patches as is [16:54:17] <BBB> and do the rest in a new patch [16:54:36] <BBB> I'd say do split + changes in a separate patch [16:54:48] <BBB> so it's clear and confirmable that the split didn't do anything funky (binary should be the same before/after) [16:57:48] <iive> 2^6 palette encoded as rgb444. [16:57:56] <BastyCDGS> BBB, how can I choose the mainline git reposity with git diff? [16:59:02] <BBB> I have no idea :-p [17:03:03] <BastyCDGS> I have found out that I can reference to master [17:03:18] <BastyCDGS> but I don't get it a file not into repository comparing with master [17:04:38] <janneg> I'm not sure what you want but it might be git diff origin/master [17:07:21] <BastyCDGS> I want git diff on a local file not in repository with mainline repository [17:07:30] <BastyCDGS> e.g. git diff /tmp/myfile.c origin/master [17:08:56] <Rigolo> good afternoon ... [17:09:14] <BastyCDGS> hi rigolo, how are u? [17:09:19] <BBB> BastyCDGS: sorry, I have no idea, either wait for more git gurus to help or go use some google magic [17:10:00] <Rigolo> I am fine ... but I have a quesion about vdpau in relation to ffmpeg/xbmc/tvheadend [17:10:40] <Rigolo> on the tvheadend trac we have a ticket open about enabling vdpau acceleration for tvheadend datastreams on xbmc [17:11:18] <Rigolo> as far as I can understand xbmc needs to have the video dimensions before it can determine if vdpau acceleration can be enabled [17:11:36] <Rigolo> but these dimensions are contained inside the mpeg data it self .. [17:12:22] <Rigolo> then I understood that there will be/is a new framework were the way vdpau works is going to be changed? [17:12:33] <Rigolo> anybody can give me some information about that? [17:13:28] <Rigolo> ideally you would like ffmpeg to see what kind of mpeg data it is receiving .. and based on that determine if it can use hw accel for decoding/displaying it [17:13:39] <Rigolo> and not give dimensions upfront [17:14:06] <Rigolo> with live TV these might be changing .. (well .. most likely only the aspect .. not the dimensions it self) [17:15:31] <BastyCDGS> BBB, first patch submitted to ml [17:15:33] <BBB> __gb__ could help you, I think you want to set AVCodecContext->pix_fmt to a hardware-based pixfmt, and then the decoder will reset it to a software pixfmt if it couldn't do hw, or reset it to its default [17:15:33] <janneg> Rigolo: the playing application should be able to decide whether it can use vdpau without outside help [17:16:23] <Rigolo> janneg: as far as I can understand it can do that by determine the dimensions upfront [17:16:24] <janneg> BastyCDGS: you want to diff a single file against awhole repository or against a single file in the repository? [17:16:53] <Rigolo> janneg: this might work for "recorded" data .. where the dimensions are available in the container .. but for live mpeg data that might be tricky to do [17:16:58] <BastyCDGS> a single file outside repo against a single file inside repository [17:17:29] <janneg> Rigolo: no, the video dimensions are also in the video data [17:18:39] <Rigolo> janneg: correct .. in the sequence headers .. but i understood that in order to use vdpau as a decoder you need to have the dimensions available [17:19:02] <Rigolo> janneg: and in order to get the dimensions you need a decoder (like vdpau) to get those [17:19:55] <Rigolo> janneg: are you suggesting that the first mpeg data should be analysed with a non vdpau decoder .. in order to determine that vdpau can work? [17:21:11] <janneg> BastyCDGS: git diff origin/master:file_a file_b [17:23:43] <janneg> Rigolo: ffmpeg has parsers for that [17:24:00] <BastyCDGS> janneg, git always says couldn't access file from master / origin, I tried origin:iff.c origin:libavcodec/iff.c and origin:/libavcodec/iff.c [17:24:10] <BastyCDGS> the same with master instead of origin [17:24:27] <Rigolo> janneg: okee ... but the idea is to analyse the mpeg data and based on that result start the vdpau decoder or not? [17:24:48] <Rigolo> and how about this new framework for harware assisted acceleration? [17:25:18] <kierank> mpc-hc does the same as well btw [17:26:50] <janneg> BastyCDGS: git diff origin/master:ffmpeg.c ffmpeg_4k.c works as expected [17:27:56] <janneg> Rigolo: I mainly wanted to point out that not using vdpau or any other (special) decoder is the players application fault [17:28:27] <Rigolo> kierank: okee ... but this means an extra delay when you want to switch/watch HD encoded live TV .. because you need to parse a few frame's of mpeg data and based in that result start a specifc decoder [17:29:23] <janneg> Rigolo: which data format do you stream to xbmc? [17:29:45] <Rigolo> janneg: unaltered mpeg data from a dvb provider [17:29:57] <Rigolo> janneg: so this can me mpeg2 or mpeg4 [17:30:14] <janneg> Rigolo: you can't prevent a couple of frames delay with b-frames [17:30:29] <janneg> and the parser should only neeed the first frame [17:31:00] <Rigolo> janneg: possibly ... but what if the aspect is changing later on? [17:31:17] <Rigolo> janneg: like the station is going to a commercial break or something like that? [17:31:21] <janneg> and we will be always a short delay after channel switches since you have to wait for keyframes [17:31:23] <kierank> that's aspect ratio [17:31:34] <kierank> resolution generally doesn't change that often [17:31:45] <Rigolo> kierank: okee .. so aspect change is not a real problem with vdpau? [17:31:46] <janneg> Rigolo: aspect ratio changes shouldn't cause problems [17:32:31] <Rigolo> janneg: correct, but ideally you would to give ffmpeg the datastream .. and let ffmpeg figure out the best way to decoded/display that data [17:32:42] <kierank> tv streams may also have AFDs so that AR changes don't have to lie on a i-frame [17:34:19] <janneg> Rigolo: I still don't see how this is related to tvheadend [17:34:52] <Rigolo> janneg: well .. people ask us to provide correct dimension data to xbmc so that xbmc can start the correct decoder [17:35:20] <Rigolo> janneg: I also told them that we are not the "problem" as we just pass the data to xbmc [17:35:22] <janneg> ignore them [17:35:53] <Rigolo> janneg: but I like to give them a correct answer .. and determine where in the chain it should/can be solved [17:36:50] <janneg> or if you're evil provide random/bogus data so that xbmc crashes if it relies on it [17:37:23] <janneg> Rigolo: it's a problem within xbmc [17:37:24] <Rigolo> janneg: well ... we try to play nice .. and stick to standards :-) [17:37:46] <Rigolo> janneg: I can understand it is either within xbmc or with ffmpeg ... [17:38:09] <janneg> or whatever xbmc uses for decoding [17:38:11] <Rigolo> like i said .. ideally you would like ffmpeg to always use the best available decoder for specific content [17:38:36] <Rigolo> xbmc is using ffmpeg [17:38:51] <BastyCDGS> BBB: all 3 patches now on ml [17:39:22] <janneg> Rigolo: it's not as simple as that, vdpau is not decoder in the classical sense [17:39:57] <Rigolo> janneg: that I also understood .. and the whole hardware accelerated decoding is also still moving ... [17:40:13] <janneg> it's a decoding and display system, i.e. it has to be setup correctly to be used [17:40:48] <janneg> Rigolo: the player application has to do that [17:41:35] <Rigolo> janneg: because it is both (decode and display)? [17:42:12] <janneg> using vdpau if possible and otherwise falling back to software decoding works well in mythfrontend (without support of the backend) [17:42:21] <janneg> yes [17:44:03] <Rigolo> janneg: but that means that mythfrontend also parses the mpeg data before it starts vdpau? [17:44:25] <kierank> and? [17:44:28] <Rigolo> janneg: because in order to start vdpau you need dimensions? [17:44:43] <Rigolo> kierank: no and .. just curious if that is the way it is implemented? [17:59:36] <Rigolo> thx for the feedback and pointers/details .. [17:59:54] <Rigolo> we will go back to xbmc developers and see what they would like to implement [19:01:34] <j0sh> just got my gsoc acceptance *high five* [19:02:33] <jai> don't want to leave you hanging ;) [19:02:39] <jai> good for you [19:02:52] <_av500_> \\\ooo/// [19:03:12] <jai> _av500_: so mentoring begins eh [19:03:32] <_av500_> not me, but yes :) [19:03:35] <Bagder> how many slots did ffmpeg get this year? [19:03:48] <_av500_> 9 or so [19:03:57] <Bagder> nice [19:04:01] <_av500_> and rb? [19:04:02] <j0sh> cool, that's pretty big compared to other projects? [19:04:26] <Bagder> 4, and one of them is gonna be interesting to you guys too: "new WMA audio codecs" [19:06:37] <_av500_> new and improved formula? [19:07:11] <Bagder> I'm not a codec guy but its about fixed-pointing some of the WMA variations [19:09:37] <jai> i guess wmapro mainly [19:09:58] <jai> also, maybe this time we could try and get this upstream? [19:09:59] * elenril throws RAS syndrome at Bagder [19:10:15] <mru> wmapro needs some serious optimisation work [19:10:22] <Bagder> jai: ... [19:10:24] <jai> j0sh: not really that huge a number [19:11:02] <jai> Bagder: the work could be done as a clean patch which can be applied to trunlk [19:11:05] <jai> *trunk [19:11:18] <Bagder> no it can't [19:11:27] <jai> why? [19:11:32] <Bagder> it's a project for rockbox and we can't use ffmpeg codecs as-is [19:11:51] <Bagder> we also have not even started discussing how to merge [19:11:57] <jai> :/ [19:12:24] <Bagder> remember I was here like a month or two ago and tried to get some feeling for how to proceed on that... [19:13:36] <Bagder> in general Rockbox hackers want to contribute back and ideally we could end up with something that would be useful for both project without custom hacks [19:13:51] <jai> that would be awesome [19:16:25] <Bagder> the rockbox guys I've talked to have however not felt any dedication from ffmpeg to receive this work, ie the words are mostly just "send us the patch", and that's not enough to motivate these guys [19:17:08] <Bagder> (I'm not personally involved in codec development) [19:21:33] <jai> Bagder: that sucks, i'm sure something somewhere was misinterpreted [19:21:40] <jai> Bagder: was this discussion on the ML? [19:21:47] <Bagder> no, here [19:21:48] <jai> Bagder: or purely on irc? [19:22:00] <Bagder> and it was just brief [19:22:04] <jai> Bagder: maybe we can get a discussion going on the ML [19:22:08] <jai> Bagder: ah [19:22:51] <BBB___> jai, isn't it like 3AM for you? [19:22:55] <BBB___> as in, shouldn't you sleep? [19:23:07] <jai> BBB___: more like 01:00 :) [19:23:17] <BBB> well I was close :) [19:23:20] <jai> BBB: caffeine ;) [19:23:52] <Bagder> the other day I got emailed from a 3rd party project wanting better ffmpeg fixed-point support that reminded me about this [19:26:07] <jai> Bagder: if someone (saratoga?) does have time, it would be great if we can run a merge proposal on the ML [19:26:17] <jai> more visibility too :) [19:29:13] <Bagder> yes, but it'd have the drawback that we'd have to get all the interested parties join your mailing list, and I bet that gets a lot of stuff that isn't related to this [19:29:28] <Bagder> ie people will hesitate [19:30:08] <Bagder> I would suggest a dedicated list for the effort [19:32:55] * mt joins the discussion [19:33:34] <Bagder> mt: what do you think is a good way forward on this? [19:34:49] <BBB> for fixedpoint codecs? [19:34:50] <mt> I like the suggestion of a dedicated ML [19:35:16] <Bagder> BBB: yes for fixed-point, getting rockbox stuff back in but also for making it more future-proof [19:35:22] <BBB> there's a problem [19:35:24] <BBB> too many MLs [19:35:29] <BBB> that's great for fragmentation [19:35:38] <BBB> but it also has the side-effect that many main (or new) developers won't sign up [19:35:39] <Bagder> yes, but the opposite is also a problem [19:35:45] <BBB> so you'll lose broad developer support [19:35:52] <BBB> i.e. I won't read it [19:36:03] <BBB> for ffmpeg, you sort of have to cherry-pick emails from the list [19:36:09] <BBB> like LKML [19:36:15] <Bagder> yes, but that's major downside [19:36:35] <Bagder> for most mortals at least [19:36:36] <mt> I'll be working on wma pro soon, so if there's any interest in rb-ff collaboration, we'd better move quickly [19:39:24] <BBB> Bagder: I'm just telling you what others might tell you as well [19:39:30] <BBB> be aware of it while asking/hoping for a new ML [19:39:32] <Bagder> I realize that [19:39:39] <BBB> and if the main developers aren't on the new list [19:39:42] <BBB> nothing will ever happen [19:39:50] <Bagder> but you and the others need to understand the other side [19:40:19] <Bagder> the rockbox guys won't just a list with 95% unrelated matters flying by at high speed... [19:40:22] <BBB> people like Michael tend to be more important because without them, the project wouldn't move - at all [19:40:25] <Bagder> s/just/joun [19:40:31] <Bagder> darnit, I can't type [19:40:42] <BBB> so the question is, should it be convenient for you or for him/us? :) [19:40:48] <BBB> anyway, just a thought [19:40:50] <Bagder> exactly [19:40:55] <Bagder> you always say YOU [19:40:55] <BBB> feel free to propose the new list :) [19:41:00] <BBB> haha :-p [19:41:06] <CIA-7> ffmpeg: stefano * r22966 /trunk/libavdevice/v4l2.c: Return meaningful error codes, rather than always -1. [19:41:07] <Bagder> and then we react with a kneejerk [19:41:17] <mt> and then silence .. [19:41:20] <Bagder> exactly [19:41:37] <Bagder> so its a question if ffmpeg wants this to happen [19:41:50] <BBB> probably [19:41:51] <Bagder> and how we can meet to make it so [19:43:03] <mt> I'm now thinking it's a little bit too early to discuss the matter of a mailing .. we should first gather the interested devs from both sides and they would decide how things should go. [19:43:09] <mt> *mailing list [19:43:25] <Bagder> you mean like an IRC meeting? [19:43:30] <BBB> which codecs are we talking about here? [19:43:41] <BBB> you guys have a fxp wma1/2dec right? [19:43:44] <kierank> irc meetings are hillarious [19:43:45] <mt> Bagder: That's what I was thinking yes. [19:43:47] <BBB> so this is about wmapro now? [19:43:59] <Bagder> kierank: so what's the alternative? [19:44:12] <kierank> nothing wrong with them per se, just funny to watch [19:44:19] <kierank> esp. the mozilla ones with their agendas [19:44:24] <kierank> run like it's a proper meeting [19:44:58] <mt> I don't find that funny, I think it's effective. :) [19:45:35] <mt> BBB: Mainly wma pro for now, as this is the one that should receive work soon. [19:47:00] <jai> mt: where do you plan on hosting the code? [19:47:05] <mt> Then in the future, new codecs would follow the same workflow (assuming one is ever decided), but I'm not sure yet if there could be anything done regarding the old codecs. [19:48:08] <mt> jai: public git repo + rockbox trunk. But I guess rockbox trunk would be enough to follow the work. [19:49:26] <jai> mt: okay [19:54:10] <mt> Who - or about how many - would be interested to work on this anyway ? from ffmpeg devs I mean. [20:01:54] <jai> i'm sure quite a few :) [20:06:10] <bcoudurier> hi guys [20:08:22] <janneg> bcoudurier: hi [20:08:40] <BastyCDGS> damn have bad news [20:08:57] <BastyCDGS> anyone read the idea about moving the calculation of the tables outside of the loop? [20:09:19] <BastyCDGS> well I tried almost everything and it's either as fast as my first solution in the patch or slower [20:09:22] <BastyCDGS> I dunno understand why [20:09:44] <_av500_> ash cloud! [20:09:51] <BastyCDGS> lol that it must be ;) [20:10:26] <BastyCDGS> the overall result is: wasting 6,5 kb of memory for the static const tables for gain of absolutely nothing [20:11:56] <BastyCDGS> anyone experienced here with L1/L2 cache stuff? [20:12:16] <BastyCDGS> could it be the issue that each lut for each plane is exactly 64 bytes long (which is usually L1 cache line) [20:12:57] <mru> cache aliasing isn't much of a problem anymore [20:13:04] <mru> it was only an issue with old direct-mapped caches [20:13:53] <BastyCDGS> if all these tables are loaded in the same cache line it has to flush everytime...should I try to make them 68 bytes long for a simple test and see if this changes anything? [20:14:17] <mru> as I said, that's not an issue on a modern cpu [20:14:35] <BastyCDGS> does the athlon xp+ count into this? [20:14:43] <mru> on old cpus you had aliasing of addresses the size of the cache apart [20:14:48] <mru> the full cache, not line [20:15:03] <mru> I would think the xp+ has at least a 4-way L1 [20:15:22] <BastyCDGS> I'll just make a short test with 68, ok? [20:15:45] <mru> if anything, that will make it slower [20:17:21] <BastyCDGS> didn't change much [20:17:35] <BastyCDGS> so what we do now? [20:17:44] <BastyCDGS> do you accept my initial patch regarding this? [20:17:55] <mru> not until I've understood what's going on [20:17:57] <BastyCDGS> or should I provide a new one using static const table for all precalc? [20:18:40] <mru> it just seems wrong to keep recalculating something that doesn't change [20:20:03] <BastyCDGS> I wonder here as same as you probably do here...I can't really explain [20:21:34] <iive> BastyCDGS: show us the code [20:21:49] <BastyCDGS> ok will prepare a patch with the new [20:21:55] <BastyCDGS> what method do you provide? [20:22:05] <BastyCDGS> s/provide/prefer [20:22:13] <iive> but have in mind that byte operations are usually painfully slow. [20:22:28] <BastyCDGS> memcpy to local stack, pointer on local stack to static const or direct access to static const table? [20:22:39] <BastyCDGS> these are all DWORD operations [20:22:48] <BastyCDGS> it was byte before ;) [20:22:54] <mru> please don't use microsoft-speak [20:22:57] <BastyCDGS> that's why we got the huge speedup ;) [20:23:06] <BastyCDGS> m$ this is asm [20:23:13] <BastyCDGS> dword ptr [20:23:14] <iive> masm :P [20:23:53] <BastyCDGS> so tell me for which of these 3 methods I shall provide the patch? [20:24:38] <mru> never memcpy [20:25:32] <BastyCDGS> remains local stack pointer to static const table or direct access static const table [20:28:15] <BastyCDGS> direct access okay? [20:30:50] <CIA-7> ffmpeg: mru * r22967 /trunk/configure: Set ARCH=c with --disable-asm, fix build [20:41:54] <BastyCDGS> both patches sent to ml [20:59:10] <mru> BastyCDGS: what files do you use for benchmarking this? [21:00:52] <BastyCDGS> just START/STOP_TIMER pair [21:01:05] <mru> yes, but what file did you decode? [21:01:22] <CIA-7> ffmpeg: rbultje * r22968 /trunk/libavutil/common.h: Write clip-related decimal numbers into hex, where they make more sense. [21:01:36] <BastyCDGS> always the same, 24bpp = Ooze.iff, 8bpp = Heart.ILBM [21:01:54] <mru> and where are those? [21:02:00] <CIA-7> ffmpeg: rbultje * r22969 /trunk/libavutil/common.h: Reindent after r22968. [21:02:51] <BastyCDGS> http://roundup.ffmpeg.org/issue1727 [21:02:58] <BastyCDGS> http://roundup.ffmpeg.org/issue1796 [21:23:05] <BastyCDGS> mru, what do you think about aligning the static const tables to a 64-byte boundary? [21:23:15] <BastyCDGS> so it starts exactly at a cache line on most cpus? [21:23:26] <BastyCDGS> have read that this can be a very good optimization? [21:23:31] <mru> it can help [21:24:32] <BastyCDGS> oh just read that my optimize-separation patch is commited to git ;) [21:24:58] <BastyCDGS> what do your benchmarks say? [21:25:06] <mru> haven't done them yet [21:29:23] <BastyCDGS> lol just another hardy ffmpeg only update ;) [21:29:41] <BastyCDGS> really funny that I'm getting this from the point on where I started developing at ffmpeg ;) [21:35:03] <BastyCDGS> btw, I have thought of to make TuComposer officially be a part of ffmpeg [21:36:07] <BastyCDGS> like with libswscale as an external repository [21:36:55] <BBB> then we'd first have to review the whole thing [21:37:08] <mru> no more externals please [21:37:18] <BastyCDGS> of course, I will prepare the HDF files for uae soon [21:38:15] <BastyCDGS> btw, BBB what's with my patches you wanted to commit? are they ok now? [21:39:32] <BBB> they're good [21:39:37] <BBB> I'm a little usy with things [21:39:41] <BBB> but I hope to commit them sometime today [21:40:20] <BastyCDGS> just want to get this stuff out of my head and go forward with a clean head ;) [21:40:49] <BBB> so what was the final judgement on the const? [21:40:56] <BBB> mru: let's vote [21:41:05] * BBB wonders whether he's still awake [21:41:32] <kierank> only 2240 over here [21:41:48] <BBB> he might b watching some soccer match in a pub or so [21:41:53] <BBB> never know for sure with those brits [21:42:15] * BastyCDGS wonders how a simple const can be such a topic :P [21:42:23] <mru> this is ffmpeg [21:42:30] <mru> the smaller the topic, the hotter it gets [21:42:33] <BBB> ah there he is [21:42:39] <BastyCDGS> lol [21:42:39] <BBB> mru: your vote decides: kill or keep? [21:42:50] <BBB> if you're indifferent I'll keep it [21:43:15] <mru> I don't care [21:43:17] <BBB> ok [21:50:58] <saintdev> mru: especially the bikeshed, that one is HOT [21:50:59] <saintdev> =p [22:01:51] <CIA-7> ffmpeg: cehoyos * r22970 /trunk/libavcodec/iff.c: [22:01:51] <CIA-7> ffmpeg: Make two functions out of #define hackery. [22:01:51] <CIA-7> ffmpeg: Patch by Sebastian Vater, cdgs D basty A googlemail [22:03:02] <BBB> huh? [22:03:03] <BBB> shit [22:03:07] <BBB> now I have to recheckout [22:03:13] <BastyCDGS> oh why? [22:03:35] <BBB> cehoyos messed up my patches just before I was about to apply [22:03:52] <BBB> anyway... [22:03:52] <BBB> l [22:03:53] <BBB> et' [22:03:53] <BBB> s retry [22:03:57] * BBB kicks IRC client [22:08:07] <CIA-7> ffmpeg: stefano * r22971 /trunk/libavdevice/v4l2.c: [22:08:07] <CIA-7> ffmpeg: Implement v4l2 input size autodetection in v4l2_read_header(). [22:08:07] <CIA-7> ffmpeg: Move check on frame size after the device is opened and after [22:08:07] <CIA-7> ffmpeg: device_try_init() is attempted. If the provided size value is 0x0, [22:08:07] <CIA-7> ffmpeg: perform a VIDIOC_G_FMT ioctl() on the device, which sets size to the [22:08:07] <CIA-7> ffmpeg: current settings. [22:24:12] <BastyCDGS> btw, before somebody forgets again, didn't you want to give me voice rights here now? [22:24:42] <mru> there you go [22:24:53] <BastyCDGS> merci ;) [22:24:58] <astrange> it won't bring you much fame [22:25:12] <Kovensky> now you have the DAU symbol! (according to #mplayer lore) [22:25:30] <BastyCDGS> I know [22:25:48] <Kovensky> and mru has the donut of the power [22:25:49] <Kovensky> ._. [22:26:38] <BBB> mru is our overlord, err, protector [22:26:46] <kierank> defender of the faith [22:27:39] <BBB> BastyCDGS: working on it... [22:27:46] <BBB> compile takes a while on my crappymac [22:28:22] <BastyCDGS> BBB, you must be telepathic, I was just thinking on how far you are with it [22:28:39] <BBB> :) [22:34:51] <BBB> still working... [22:35:12] <BBB> ok, all works now [22:35:53] <BastyCDGS> oh just got the invitation to gsoc students list [22:41:12] <BBB> congratulations, you're in the program :) [22:41:17] <BBB> so the patches are in now [22:41:23] <BBB> somehow CIA-* didn't get that [22:41:25] <BBB> (yet?) [22:41:36] <BBB> if any patches are missing, let me know [22:41:38] * BastyCDGS bows gracefully [22:41:44] <BastyCDGS> *bong* [22:41:48] <BastyCDGS> *ouch* :) [22:41:50] * BBB kicks CIA-7 [22:41:50] <CIA-7> ow [22:41:57] <BastyCDGS> lol [22:41:59] <BBB> hm, it didn't hang [22:42:02] <BBB> ohwell [22:42:05] <BBB> it's probably just slow [22:42:31] * saintdev hugs CIA-7 [22:42:31] * CIA-7 hugs saintdev [22:42:58] * BastyCDGS greets CIA-7 [22:43:12] <BastyCDGS> no reply, pah [22:43:31] * BBB slaps CIA-7 [22:43:38] <BBB> I guess the bot isn't very smart [22:43:49] <saintdev> BBB: no, but... [22:43:52] * saintdev eats CIA-7 [22:43:52] * CIA-7 tastes crunchy [22:43:57] <saintdev> it is crunchy :) [22:43:59] <BBB> hehe :) [22:44:21] * BastyCDGS greetz CIA-7 [22:44:24] <BastyCDGS> this way maybe? [22:44:36] * _troll_ trolls CIA-7 [22:44:44] * BastyCDGS gives fish to CIA-7 [22:44:50] <BastyCDGS> doesn't work also hmm [22:45:58] * saintdev rubs CIA-7's tummy [22:45:58] <CIA-7> *purr* [22:48:12] <BastyCDGS> BBB, well my patches seem to be in: [22:48:13] <BastyCDGS> http://git.ffmpeg.org/?p=ffmpeg;a=shortlog [22:48:20] <BastyCDGS> it's just CIA... [22:48:59] <BBB> that's ok [22:49:05] <BBB> now how's that iff/anim patch coming along? [22:50:41] <astrange> hmm vlc has 3 different projects to rewrite their mkv demuxer [22:50:48] <BastyCDGS> as said before I go on with anim I will fix EHB/HAM [22:50:58] <Kovensky> astrange: they have an mkv demuxer? [22:51:03] <BastyCDGS> maybe I also fix 8SVX before [22:51:40] <astrange> it might be a lavf wrapper, i haven't looked [22:51:57] <saintdev> astrange: it uses libebml/libmatroska [22:53:08] <BastyCDGS> BBB, you have applied the patch where I optimized decodeplane8/32 to a single-loop but still byte [22:53:26] <BastyCDGS> should I redo my current patches with the newer opts then? since they expect the very old code [22:53:31] <BastyCDGS> i.e. the double-loop [22:54:47] <_troll_> yes, please updated your patches against current svn [22:56:40] <BBB> patches should be against svn [22:56:41] <BBB> so yes [22:56:48] <BBB> and maybe start a new thread [22:56:49] <BBB> I'm confused [22:56:55] <Kovensky> git rebase ftw [22:57:28] <BastyCDGS> good idea ;) [22:57:41] <BastyCDGS> fuck [22:57:41] <BastyCDGS> libavcodec/iff.c: needs update [22:57:41] <BastyCDGS> fatal: Entry 'libavcodec/iff.c' not uptodate. Cannot merge. [22:57:41] <BastyCDGS> Merge with strategy recursive failed. [22:57:55] <BBB> welcome to merge hell ;) [22:58:13] <BastyCDGS> just did git pull ;) [22:58:14] <BBB> ok, good luck on that one, I'm going home, family's waiting :) [22:58:20] <Kovensky> BastyCDGS: yes, that's why you don't just `git pull`, you do `git pull --rebase` :) [22:58:35] <_troll_> and commit your changes first [22:58:47] <Kovensky> undo the merge (`git checkout HEAD`), then do `git rebase origin/master` [22:58:57] <Kovensky> and yes, make sure you have no non-stashed or committed changes [23:20:41] <BastyCDGS> looked like i screw up my local repo... [23:20:49] <BastyCDGS> just did rm -rf and doing a git clone [23:20:53] * BastyCDGS looks ashamed [23:27:35] <BastyCDGS> mru, shall I resend both patches? i.e. the one before the static const table outside and the other as well I did before this? [23:45:39] <BastyCDGS> submitted all 4 patches to ml into a new thread as suggested [23:45:43] <BastyCDGS> good night, goto bed now

1 0

IRC log for 2010-04-25
by irc＠mansr.com 26 Apr '10

26 Apr '10

[00:01:10] <Yuvi> dmesg? [00:02:07] <Dark_Shikari> ugh. I can't get oprofile to work on vmware [00:02:17] <Dark_Shikari> everything I read on the internets says it works if you use the timer interrupt [00:02:20] <Dark_Shikari> which I set on [00:02:32] <Dark_Shikari> but when I try to start it, it says "couldn't start oprofiled. check the logfile and kernel syslog" [00:02:35] <Dark_Shikari> but BOTH are empty [00:02:44] <Dark_Shikari> --verbose=all does nothing [00:02:48] <Dark_Shikari> it does not print any information anywhere [00:04:19] <Dark_Shikari> oh. apparently I have to manually specify -e=timer or else it won't figure it out, even though it's the only event avialable [00:08:31] <Dark_Shikari> oh sweeeeet [00:08:38] <Dark_Shikari> oprofile correctly gets the symbols of asm functions, while callgrind doesn't [00:09:01] <Dark_Shikari> ... on the other hand, it doesn't seem to provide any information about the call stack... [00:09:50] <Dark_Shikari> Is there anything special I have to do with oprofile to get it to track the stack ? [00:40:14] <Dark_Shikari> is there a good way to infinitely cat a file into an app? [00:40:20] <Dark_Shikari> e.g. the equivalent of cat file file file file ... | app [00:40:23] <Dark_Shikari> without typing "file" a thousand times [00:43:36] <trollski> Dark_Shikari: while :; do cat file | app; done [00:43:45] <Dark_Shikari> won't that repeatedly start app over again? [00:43:47] <Dark_Shikari> I don't want to do that. [00:43:50] <trollski> yeah [00:48:10] <trollski> Dark_Shikari: maybe in two steps? while :; cat file >> newfile; done ...... and second separate step: cat newfile | app .... dunno if that'll work [00:48:18] <Dark_Shikari> Too large [00:48:23] <Dark_Shikari> I don't have disk space for that [00:48:27] <Dark_Shikari> I'm piping terabytes around [00:48:31] <trollski> oh [00:49:02] <hyc> just do all the cats inside a script [00:49:07] <hyc> or subshell [00:49:08] <astrange> i wrote a program to do it in haskell and accidentally evaluated the tail of an infinite list [00:49:20] <Dark_Shikari> hyc: how does that help me? [00:49:37] <hyc> (while :; do cat foo) | app [00:49:46] <hyc> then there's only a single pipe / app [00:50:08] <Dark_Shikari> also, -loop_input doesn't work in ffmpeg [00:50:42] <Dark_Shikari> hyc: that gives a syntax error [00:50:49] <hyc> well duh [00:50:53] <hyc> it also only has a single filename [00:51:01] <Dark_Shikari> huh? [00:51:01] <hyc> you need to tailor it to your actual usage [00:51:06] <Dark_Shikari> um, but I only want a single file [00:51:10] <Dark_Shikari> ... [00:51:14] <hyc> oh? [00:51:20] <hyc> it's the same file over and over? [00:51:34] <hyc> I thought you wanted to cat a bunch of files [00:51:49] <Dark_Shikari> .... [00:51:52] <Dark_Shikari> that's what I said like 5 times [00:52:03] <Dark_Shikari> I'm saying your syntax is simply wrong, irrespective of what I'm trying to do [00:52:06] <Dark_Shikari> because it isn't valid bash [00:52:17] <hyc> then just this (while 1; do cat foo; done) | app [00:52:48] <Dark_Shikari> s/1/true [00:53:10] <hyc> right [00:53:52] <Dark_Shikari> woot, works [00:53:57] <Dark_Shikari> just got past the first repeat point [00:53:59] <hyc> you're supposed to know the syntax, I was just telling you that using a subshell is the right approach [00:54:04] <Dark_Shikari> k, thx [00:57:01] <hyc> oprofile has been pretty fragile in my experience [00:57:12] <hyc> works on one install, do an upgrade, it's broken [00:57:47] <hyc> and yes, to get stacks recorded, you need to set other oprofile options [00:57:52] <hyc> probably an opcontrol switch [00:57:58] <Dark_Shikari> I did, -c=20 [00:58:07] <Dark_Shikari> Still doesn't actually work. [00:58:32] <hyc> oh well. [00:58:45] <hyc> what are you profiling? [00:58:56] <hyc> and what data do you want to extract from the profile? [00:58:59] <Dark_Shikari> x264, I'm trying to get a proper CallMap profile, i.e. that really nice kcachegrind interface [00:59:18] <Dark_Shikari> valgrind-based callmap profile works great, but it doesn't read the names of asm functions correctly [00:59:21] <Dark_Shikari> and the results are very inaccurate [00:59:29] <Dark_Shikari> oprofile-based profile is highly accurate and good, but callmap doesn't work [00:59:47] <hyc> that's odd. I've used valgrind trace before with success. though, no asm functions. [01:00:40] <hyc> It must depend on your binary, if the assembly code doesn't provide stack usage hints then the tools can't backtrace thru it [01:00:49] <Dark_Shikari> No, no, it can't even READ THE SYMBOLS [01:01:02] <Dark_Shikari> and oprofile doesn't provide callmap information _even for C functions_ [01:01:13] <hyc> yeah well, oprofile breaks a lot [01:02:14] <Dark_Shikari> well callgrind not being able to read symbols sorta sucks too [01:02:36] <hyc> what architecture are you running? [01:02:40] <Dark_Shikari> x86_64 [01:02:58] <hyc> got a 32 bit machine handy? that will probably work better [01:03:01] <Dark_Shikari> why [01:03:12] <hyc> generally x86 is better supported than x86-64 [01:03:25] <Dark_Shikari> doubt that symbol formats differ that much [01:03:56] <hyc> no, probably not. but libbfd and friends are more mature for 32 bit [01:04:01] <Dark_Shikari> it's easy enough to test though, just cross-compile [01:07:52] <hyc> also if all you want is the callmap, turn off all optimization [01:08:01] <Dark_Shikari> why? [01:08:13] <Dark_Shikari> as long as you don't use -fomit-frame-pointer, it shouldn't prevent the callmap from working [01:08:17] <hyc> because stuff like omit-frame-pointers really interferes [01:08:37] <hyc> and -fomit-frame-pointers is the default on -O2 and up [01:08:57] <Dark_Shikari> oh true, x86_64 [01:09:07] <Dark_Shikari> wait, I thought it was the default _because_ it didn't interfere on x86_64 [01:09:23] <hyc> false, it is still a problem [01:09:38] <hyc> look at a stack trace in gdb... [01:09:58] <Dark_Shikari> then why is it on by default in x86_64 but not x86_32? [01:10:07] <hyc> dunno [01:10:40] <hyc> whatever, do what you like [01:10:50] <hyc> it's your time not mine... [01:13:19] <Dark_Shikari> wrong [01:13:20] <Dark_Shikari> didn't work [01:13:27] <Dark_Shikari> even in debug mode, the callee map doesn't show up. [01:13:29] <Dark_Shikari> (-O1 -g) [01:15:44] <saintd3v> what about adding "-g dwarf2" to ASFLAGS? [01:15:59] <hyc> dwarf2 ought to be the default format [01:16:09] <Dark_Shikari> doesn't matter anyways, _even the C functions_ don't have callmap [01:16:13] <saintd3v> oic [01:16:31] <saintd3v> hyc: but iirc you have to pass _something_ to yasm if you specify -g [01:16:53] <hyc> ah, dunno. [01:16:53] <saintd3v> ie you can't do just yasm -g it has to be yasm -g foo [01:17:04] <hyc> I just use gas [01:17:28] <saintd3v> but if C functions aren't showing up it's moot anyway [01:18:25] <hyc> yep. I've submitted patches for oprofile in the past, but for whatever reason that thing keeps breaking [01:18:48] <hyc> have no idea why valgrind wouldn't work, usually it's pretty good [01:19:43] <hyc> the only reason it fails to show symbols, for my work, is because of shared libs that got unloaded [01:20:04] <hyc> it's still too stupid to record the sharedlib info at the time of load [01:21:32] <saintd3v> Dark_Shikari: i doubt it'll help, but -g3? [01:22:23] <saintd3v> and what about disabling all optimizations? [01:22:38] <hyc> btw, are you using the latest? valgrind 3.5? [01:23:23] <Dark_Shikari> I'm not using valgrind, I'm using oprofile [01:23:35] <Dark_Shikari> and yes when I did try valgrind, I used 3.5 [01:35:52] <Dark_Shikari> http://x264.nl/x264_Demo_Blu-ray.torrent <--The first free Blu-ray [01:35:55] <Dark_Shikari> download, seed [01:36:00] <Dark_Shikari> official announcement is coming on monday [01:36:13] <pentanol> hello, could someone point me which of these options important for usage? http://codepad.org/BEeo3wsm [02:28:40] <astrange> -fomit-frame-pointer still breaks frame pointer backtraces on x86-64, yeah [02:28:53] <astrange> i don't remember its defaultness changing on either arch [02:29:31] <astrange> valgrind _could_ maintain a separate call stack, or it could read dwarf unwind info (with the weirdly named -fasynchronous-unwind-tables or whatever) [02:29:43] <Dark_Shikari> valgrind works even if fomit-frame-pointer is set [02:31:40] <astrange> i don't remember any specific situations but i'm pretty sure it hasn't worked for me before [04:30:08] <mru> Dark_Shikari: while :; cat file; done | app [04:30:21] <mru> maybe you figured it out by now though... [04:31:08] <Dark_Shikari> yeah, I did [10:38:51] <twnqx> in which include is NULL defined? :X [10:45:34] <jai> twnqx: linux/stddef.h [10:45:41] <twnqx> thanks [10:47:57] <jai> on *bsds, i think it is in sys/null.h [10:51:00] <twnqx> btw jai, my syscall hook works now :P [10:51:07] <jai> twnqx: yay [10:51:10] <jai> :) [10:51:53] <twnqx> sadly the driver doesn't. [10:52:05] <twnqx> it also fubared my kernel. gotta reboot... [10:52:11] <jai> twnqx: oh :| [10:53:06] <twnqx> seems i have to modify some undocumented private ioctls as well. fun :D [10:53:27] <twnqx> but computers MUST NOT win against humans. [10:54:27] <kshishkov> twnqx, you're sooo wrong [10:54:53] <twnqx> true, in this case it's not the computer [10:54:59] <twnqx> but two companies that must not win. [10:55:28] <kshishkov> I'm pretty sure each of them agrees that another one should not win [10:56:00] <jai> twnqx: perhaps you'll reach a point where you might just want to pay them money for an x86_64 build :) [10:56:29] <twnqx> jai: the 64bit is not the real problem [10:56:49] <twnqx> the problem is that EITHER WAY i don't have a driver for post-2.6.16 kernels [10:57:15] <twnqx> i got myself a demo version of the current windriver 10 now [10:57:19] <jai> twnqx: ah [10:57:39] <twnqx> however... the app says "oh, you need > version 8.02" and i have 10.11 [10:57:54] <twnqx> i have the strong feeling that they do numerical comparison on the chars [10:58:11] <twnqx> so, 1 < 8 => fail [10:58:57] <twnqx> and since the driver is a blob again... with some exra fail like embedded integrity checks... [10:59:21] <twnqx> *sigh* [11:00:33] <twnqx> the good news for today is that my favorite german radio station does have a pure mp3 http stream with no protection, so i can skip the crappy flash plugin on their site and just use mplayer. [12:08:00] <BastyCDGS> hi @ all [12:16:48] <DimStar> how "final" is Michael's not liking anything as decision wether a patch is being merged or not? ( https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/087300.html ) [12:49:38] <BastyCDGS> I got stuck with START/END_TIMER...it doesn't output anything [12:49:56] <BastyCDGS> START/STOP_TIMER [13:29:55] <Kovensky> In file included from libavdevice/oss_audio.c:31: [13:29:55] <Kovensky> /usr/include/sys/soundcard.h:243:5: error: unknown type name 'u_long' [13:30:08] <Kovensky> ^ ffmpeg's or the system's fault :S [13:30:59] <elenril> your =p [13:31:16] <Kovensky> =p [13:31:32] <Kovensky> just wondering if sys/soundcard.h demands that some header is included before it but even then it's weird [14:05:56] <nfl> does anyone now how to modify the post commit email payload in github? [14:05:57] <nfl> I was asked to look at github for hosting my soc code but the post commit mail doesn't include the diff [14:07:50] <Kovensky> libavcodec/h264.h:1256:13: warning: unused function 'decode_mb_skip' [-Wunused-function] [14:08:22] <Kovensky> nfl: hmm, does it include a bit.ly link? at least their cia.vc module does [14:08:28] <Kovensky> the bit.ly link points to the diff on github.com [14:10:26] <nfl> Kovensky: it does include a link to the diff but i suppose reviewing wouldn't be as easy [14:18:57] <nfl> perhaps the soc repo should be moved to git ;) [14:22:17] <Kovensky> hmm [14:22:25] <Kovensky> you should bug the github people then :) [14:22:30] <Kovensky> don't know how to contact them though [14:23:22] <BastyCDGS> so hope my iff optimize patch is now ready for git ;) [14:23:29] <BastyCDGS> just submitted it to ml [14:23:43] <BastyCDGS> also included benchmarks [14:24:15] <nfl> Kovensky: http://support.github.com/discussions/post-receive-issues/16-diff-in-email-… :( [14:25:04] <Kovensky> bug them again? :) [14:25:07] <Kovensky> that ticket is almost a year old [14:26:08] <nfl> I'll have to try that [14:28:37] <CIA-7> ffmpeg: stefano * r22961 /trunk/ (20 files in 2 dirs): [14:28:37] <CIA-7> ffmpeg: Mark av_metadata_set() as deprecated, and use av_metadata_set2() [14:28:37] <CIA-7> ffmpeg: in its place. [14:28:37] <CIA-7> ffmpeg: av_metadata_set() is going to be dropped at the next major bump. [15:06:10] <CIA-7> ffmpeg: stefano * r22962 /trunk/libavcodec/utils.c: [15:06:10] <CIA-7> ffmpeg: Make avcodec_check_dimensions() return AVERROR(EINVAL) rather than -1 [15:06:10] <CIA-7> ffmpeg: in case of invalid picture size. [15:44:04] <BastyCDGS> just a question regarding interleaved stereo audio output [15:44:26] <BastyCDGS> can I call av_new_packet(pkt, PACKET_SIZE) twice? [15:44:33] <BastyCDGS> one for left channel and one for right channel? [15:46:56] <Kovensky> not in the same pkt [15:47:08] <Kovensky> look in libavcodec/avpacket.c for what it does [15:48:13] * Kovensky fails at understanding "if((unsigned)size < (unsigned)size + FF_INPUT_BUFFER_PADDING_SIZE)" (isn't that always true except for negative size, and wtf allocates a negative sized buffer) [15:50:32] <elenril> Kovensky: overflow [15:51:44] <Kovensky> elenril: doesn't check for overflow either, unless (unsigned) has lower precedence than + [15:53:20] <elenril> whatever, i don't know c anyway ;) [15:53:25] <Kovensky> lol [15:55:29] <elenril> srsly i don't [15:55:31] <pengvado> yes it's for overflow [15:55:53] <mru> that code is wrong [15:56:08] <mru> the test checks for unsigned overflow [15:56:17] <mru> then it goes ahead and does a signed addition [15:57:00] <Kovensky> what mru said [15:57:45] <Kovensky> and you couldn't have an unsigned int overflow anyway with an int var [15:58:11] <Kovensky> not with regular casts at least ._. [15:59:28] <mru> if there is signed overflow, behaviour is undefined or unspecified, don't remember which [15:59:54] <mru> the size argument should have been unsigned [16:00:53] <Kovensky> mru: wouldn't INT_MAX+1 go to INT_MIN [16:00:57] <mru> no [16:01:02] <mru> it's undefined [16:01:07] <Kovensky> hmm [16:01:18] <Kovensky> I guess that's just the case with x86 then ._. [16:01:22] <BBB> this works: 1+((int64_t)INT_MAX) [16:01:31] <mru> don't even think about that [16:01:38] <BBB> I didn't say you should use it ;) [16:01:42] <BBB> I just said it works ;) [16:01:52] <BBB> but please don't take my svn commit access away [16:01:56] <Kovensky> you cheater :P [16:01:57] <elenril> lol [16:02:00] <Kovensky> lol [16:03:39] <BastyCDGS> can anyone tell me what's wrong with this small piece? [16:03:45] <BastyCDGS> if ((ret = get_buffer(pb, sample_buffer, PACKET_SIZE >> 1)) < 0) [16:03:45] <BastyCDGS> return AVERROR(EIO); [16:03:45] <BastyCDGS> old_pos = url_fseek(pb, iff->body_size >> 1, SEEK_CUR); [16:03:45] <BastyCDGS> if ((ret = get_buffer(pb, sample_buffer + (PACKET_SIZE >> 1), PACKET_SIZE >> 1)) < 0) [16:03:45] <BastyCDGS> return AVERROR(EIO); [16:03:46] <BastyCDGS> url_fseek(pb, old_pos, SEEK_SET); [16:04:04] <BastyCDGS> I'm just fixing the interleaved stereo support for IFF-8SVX [16:04:30] <BastyCDGS> and I added the fseek stuff to seek to the right channel [16:04:39] <BastyCDGS> but when I run it plays only one frame and then silence [16:04:54] <jai> ? [16:04:58] <Kovensky> ugh, reminds me that I still must figure out wtf I'm doing wrong in my stuff... [16:05:09] <Kovensky> for some reason the mp2 decoder is dying with Broken Header when decoding the 3rd frame ._. [16:05:16] <jai> as i said in the mail earlier, just use the ff_interleave code [16:10:25] <BastyCDGS> jai, you mean the interleave_sample from iff.c or another interleave stuff? [16:10:44] <jai> BastyCDGS: lavf/audiointerleave.c [16:10:46] <BBB> how do I compile/run 64-bits code on a macintel? [16:10:53] <BBB> (assuming it can run it...) [16:11:19] <BBB> not which configure command, but which gcc command? [16:11:22] <jai> after that you can remove the interleaving code in iff.c [16:11:32] <BastyCDGS> btw, is my new patch regarding optimizing okay? [16:12:36] <mru> I'd rather you separated the structural changes from the unsigned/shift ones [16:14:04] <BastyCDGS> you mean the structural changes I did because of getting rid of branch prediction inside the loops? [16:14:53] <BBB> what's the difference? it's ~1% if I read it correctly, for this particular function? [16:14:58] <BBB> that's not very much [16:15:20] <jai> :) [16:15:46] <BastyCDGS> no this is only for plane decoding...i think the overall diff will be around 2% [16:16:01] <jai> well ..../ [16:18:43] <BastyCDGS> a mispredicated branch prediction is 10-20 clock cycles [16:19:25] <BastyCDGS> I removed 4 branches in the main loop decoding the image that's a save of 40-80 clock cycles per pixel [16:20:02] <mru> branch prediction isn't really the issue here [16:20:22] <mru> after a couple of iterations the predictor will have learned which branch is being taken [16:20:27] <mru> since it's the same each time around [16:20:47] <BastyCDGS> you think I should revert the changes there I made? [16:20:50] <mru> no [16:21:12] <BastyCDGS> so just split the patch up and it will be fine? [16:21:16] <mru> I'm just saying branch _prediction_ is not the reason for making such changes [16:21:34] <mru> you simply want to reduce the number of instructions in tight loops [16:22:21] <mru> in an otherwise small loop, a few branches can increase the size significantly [16:22:30] <mru> running more instructions obviously takes longer time [16:22:30] <BastyCDGS> this is a neat side-effect here anyway, removing branches completely will do this ;) [16:22:40] <mru> and spreading the loop body over more cache lines is bad [16:25:26] <BastyCDGS> I did take a look on the disasm output, too. it really looks much better [16:25:50] <mru> I'm not disputing that [16:25:52] <BastyCDGS> so finally, what I shall do now for getting this patch into mainline git tree? [16:26:06] <mru> as I said, do the loop restructuring as one patch [16:26:18] <BastyCDGS> okey, wait a minute, plz ;) [16:26:19] <mru> and the micro-opts as another [16:34:25] <BastyCDGS> the micro opts only patch is finished, can I send both patches in one post? [16:35:14] <BBB> I normally wouldn't [16:35:16] <BBB> but you can try [16:35:21] <mru> use git send-email [16:36:05] <BastyCDGS> btw, should I put my copyright notice also in a separate patch? [16:36:34] <kshishkov> no [16:45:18] <BastyCDGS> btw, what is the difference between git checkout and git pull? [16:45:33] <BastyCDGS> I noticed that I had to do git pull to get the data from the mainline repo [16:45:36] <mru> everything [16:45:46] <BastyCDGS> while git checkout said merged my local changes [16:45:52] <mru> pull is the same as fetch followed by merge [16:46:04] <mru> read the documentation [16:46:12] <mru> it's all explained there better than I could do here [16:46:24] <BastyCDGS> ok I should do this, but I was trying to find that out by myself by doing git --help ;) [16:46:52] <BastyCDGS> after all I can now work a bit with git...I didn't use svn since then, btw [16:47:05] <elenril> why would you want to ;) [16:48:21] <BastyCDGS> so both patches now on ml [16:50:01] <jai> how is your qualification task coming along? [16:50:55] <BastyCDGS> it slowed down a bit due the case I want to do EHB/HAM first in plain ILBM [16:51:09] <BastyCDGS> thus fix the plain ILBM decoder first [16:51:23] <BastyCDGS> before I have to do everything twice... [16:51:50] <BastyCDGS> EHB will be finished today [16:52:46] <kshishkov> good, FFmpeg is about fringe formats [16:53:27] <kshishkov> with some fast decoders for standard codecs added for cheap popularity [16:55:00] <BastyCDGS> mru, dropped the spaces in [] and updated patch in ml [16:55:19] <mru> you don't need to resend patches for such tiny changes [16:55:31] <mru> it's better to wait for more reviews first [16:55:41] <BastyCDGS> okay [16:59:44] <kshishkov> hej [17:00:08] <BastyCDGS> so the rest is fine then? [17:00:49] <kshishkov> just wait for more replies [17:04:40] <BastyCDGS> regarding ff_audio_rechunk_interleave, the two AVPacket's there are one for left and right channel right? [17:06:39] <BBB> BastyCDGS: learn to wait 24-48 hrs for reviews [17:06:43] <BBB> reviews can take time :) [17:07:05] <BastyCDGS> ok, I'll continue then with EHB now [17:07:23] <kshishkov> yes, the more you can deliver the better [17:09:29] <BBB> so kshishkov, do you want crashers I see in vc1dec as I add wvp2? [17:09:33] <BBB> kshishkov: there's quite a few [17:09:46] <BBB> kshishkov: basically every single wvp2/wmvp sample crashes the vc1 decoder ;) [17:10:02] <kshishkov> no error messages? [17:10:06] <BBB> Bus Error [17:10:12] <BBB> which is like a segfault [17:10:16] <kshishkov> that's strange [17:10:24] <kshishkov> IIRC it should fail on parsing extradata [17:10:30] <BBB> it does [17:10:34] <mru> BBB: what system is that on? [17:10:35] <BBB> if I remove that, vc1dec crashes [17:10:38] <BBB> mru: mac [17:10:45] <mru> hmm [17:10:49] <BBB> kshishkov: I added etradata parsing [17:10:59] <BBB> kshishkov: but the actual decoding is still in progress [17:11:09] <kshishkov> good! [17:11:13] <BBB> not really :) [17:11:16] <BBB> but anyway [17:11:28] <kshishkov> what gdb says? [17:11:30] <mru> bus error usually means either invalid unaligned access or access to some kind of totally invalid address [17:11:47] <BBB> I didn't run it in gdb [17:11:49] <BBB> I'm lazy [17:11:56] <BBB> if I give you a crashing sample will you look at it? [17:12:07] <BBB> if you say no, I won't bother [17:12:12] <BBB> if you say yes, I'll file some reports [17:12:13] <kshishkov> no [17:12:23] <mru> wrong answer [17:12:27] <kshishkov> I've moved to another town and all I have now is Gdium [17:12:37] <BBB> :) [17:12:38] <BBB> what is gdium? [17:12:45] <mru> sorry excuse of a netbook [17:12:59] <kshishkov> and a portable stove! [17:13:07] <mru> yeah, all in one [17:13:17] <jai> lol [17:13:18] <mru> only missing the kitchen sink [17:13:38] <jai> better than what richard stallman uses i'd say [17:13:50] <mru> what does he use? [17:13:54] <kshishkov> does he still use Lisp machine? [17:13:57] <BBB> a kitchen cave [17:13:58] <mru> does he code directly on his ego? [17:14:23] <mru> oh, wait.. rms doesn't actually write code [17:14:32] <mru> he just jumps up and down and shouts a lot [17:14:43] <kshishkov> worked fine for GCC [17:15:02] <mru> I doubt there's a single line of code in gcc he wrote [17:15:29] <kshishkov> and Emacs was written by Sun guy who later worked on Java [17:15:36] <mru> that was vi [17:15:44] <kshishkov> Emacs [17:15:56] <mru> emacs has been worked on by very many people [17:16:08] <mru> but the sun guy is famous for vi [17:16:19] <kshishkov> yes, but first opensource version was written by some Sun guy [17:17:27] <jai> yeelong actually : http://richard.stallman.usesthis.com/ [17:17:39] <kshishkov> mru: yep, Gosling [17:18:00] <kshishkov> jai: that's even more Chineese that Gdium but of the same source [17:18:31] <jai_menon> meh [17:18:45] <mru> what an idiot [17:18:54] <mru> why doesn't he get a pc and put seabios on it? [17:19:01] <jai> anyway, so he uses a yeelong - http://richard.stallman.usesthis.com/ [17:19:34] <jai> and yeah, after the egcs merge i dont think there is any significant gcc code written by him left [17:19:38] <kshishkov> heh, even I use better netbook :) [17:19:49] <BBB> no wonder the guy doesn't code [17:19:55] <BBB> his laptop is a PoS [17:20:08] <mru> isn't yeelong the one with incompatible cpu and northbridge? [17:20:22] <mru> how they made it run at all is a bit of a mystery [17:20:55] <kierank> [18:20] <@BBB> his laptop is a PoS --> yes but it's "free" [17:21:05] <BBB> freetard argument alert [17:21:19] <mru> but the cpu itself isn't free [17:21:26] <kierank> tell him that [17:21:42] <kshishkov> why don't we have anything useful Sparc-based? [17:21:49] <kshishkov> _that_ CPU is free [17:21:49] <mru> and there are much better systems with fully free software [17:23:05] <mru> oh, and I think it's about time rms accepted that linus stole the show [17:23:24] <kshishkov> you just wait for GNU Hurd! [17:23:30] * kierank waits [17:23:42] <jai> Real Soon Now [17:23:48] <kshishkov> kierank: you can make a cup of coffee meanwhile [17:23:54] <mru> and either way, the insistence on saying gnu/linux is insane [17:24:06] <kshishkov> from the beans of plantation you ground this day [17:24:23] <mru> if we want to be accurate, we should say, gnu/bsd/x/kde/gnome/mozilla/linux [17:24:26] <mru> or something [17:25:06] <drv> average joe desktop/gui user probably doesn't even touch the GNU stuff anyway [17:25:16] <jai> plan 9 ftw? [17:25:20] <BBB> gnume/linux [17:25:35] <mru> I installed plan9 in a vm once [17:25:42] <mru> most useless system ever [17:27:31] <jai> lol [17:27:41] <jai> i used it for werc at some point [17:28:15] <kshishkov> so you agree? [17:30:03] <jai> in a way, yeah. perhaps i'm not able to appreciate the awesomeness [17:31:26] <kshishkov> not piped for it [17:37:59] * _av500_ welcomes kshishkov back from whereever he has been [17:38:22] <kshishkov> _av500_: at least now it's 200km closer to Stockholm [17:39:07] <_av500_> they physically moved kharkov? [17:39:16] <kshishkov> no, I physically moved from there [17:39:35] <_av500_> for vacation? [17:39:37] <kshishkov> had to get a work for that though [17:39:53] <_av500_> a work [17:40:10] <kshishkov> yep [17:40:21] <pJok> its alive and back! [17:40:28] <pJok> god kväld, kshishkov :) [17:40:42] <pJok> err [17:40:44] <pJok> kväll [17:40:51] <kshishkov> and a bunch of good evenings to you too [17:41:03] <_av500_> kiev? [17:41:44] <kshishkov> karlsruhe [17:43:27] <_av500_> wow [17:44:53] <kshishkov> Kiev sucks, so I'd move there only at gunpoint [17:45:22] <_av500_> who do you work for? [17:45:31] <kshishkov> Cinemo [17:46:40] <BastyCDGS> one question, how do I do the following with git? [17:46:57] <BastyCDGS> I have now the noindent patch ready of restructuring optimization patch [17:47:12] <BastyCDGS> I want now to commit this locally and just correct indentation and create a correct patch [17:47:48] <_av500_> kshishkov: nice [17:48:16] <kshishkov> _av500_: yes, I think so [17:48:33] <BastyCDGS> can I do sth. like git diff file1 local_repo? [17:49:01] <mru> just create the commits in your local repo [17:49:10] <mru> the git svn dcommit them all at once [17:49:24] <_av500_> kshishkov: you are herewith invited to a non-alcoholic beverage of your choise here any time [17:49:27] <BastyCDGS> svn dcommit? [17:49:46] <BastyCDGS> I'm not using git-svn [17:49:49] <BastyCDGS> just plain git [17:49:56] <mru> oh, wait... you don't have commit rights do you? [17:50:05] <kshishkov> _av500_: oh, thanks [17:50:11] <BastyCDGS> no I haven't commit rights [17:50:25] <mru> BastyCDGS: still, do the commits locally [17:50:45] <mru> then "git format-patch origin" should give you a nice patch series [17:51:18] <elenril> even better, git send-email [17:51:33] <mru> yeah, that's even better [17:51:44] <BastyCDGS> I prefer writing mails to ML with thunderbird so I have all sent/received mails in one program [17:52:10] <mru> you'll get them back from the ML [17:52:14] <elenril> sending multiple patches is :effort: [17:52:24] <BastyCDGS> oh then I didn't say anything ;) [17:52:51] <mru> git send-email will ask you for an address to send to [17:53:07] <mru> you can set a default in the repo configuration [17:53:14] <_av500_> git cant figure that out by itself? bah [17:53:16] <mru> man git-send-email should say how [17:53:20] <BastyCDGS> I have already configured git for using my email adress and name for sending [18:07:49] <Dark_Shikari> calling on the cabal [18:07:54] <Dark_Shikari> http://www.reddit.com/r/programming/comments/bvwi5/x264_project_announces_f… http://news.ycombinator.com/item?id=1293135 http://slashdot.org/submission/1223280/x264-Project-Announces-Blu-ray-Encod… [18:07:58] <Dark_Shikari> upvote me [18:08:11] <kshishkov> ask xiph [18:08:14] <BastyCDGS> mru, short question regarding your critics...shall I do the correct indentation from start only for larger blocks of new code, or can I do that with any line marked by the patch as + ? [18:08:23] <Kovensky> <@mru> you'll get them back from the ML <-- not if you use gmail :( [18:08:32] <Kovensky> at least it completely ignores ML echoes [18:08:37] <mru> Kovensky: wtf? [18:08:47] <kshishkov> good night, I'll try to come here more often [18:08:57] <BastyCDGS> I also didn't get back the messages I sent to ml [18:09:19] <BastyCDGS> but they're at least in my sent folder [18:18:16] <BastyCDGS> so noindent patch should be fine now, mru ;) [18:18:17] <jai> BastyCDGS: btw, are you french? [18:19:03] <BastyCDGS> my native language is german, but since I moved to french speaking part of belgium 1.5f years ago, I have switched locale from de_DE to fr_BE for better learning of french [18:22:07] <jai> BastyCDGS: ah [18:22:20] <jai> should be fun [18:22:25] <BastyCDGS> you were wondering about my a ecrit in my reply messages, right? ;) [18:22:30] <jai> yep [18:23:19] <jai> using it for everyday communication should help a lot [18:23:40] * jai 's french is pretty rusty :( [18:24:21] * BastyCDGS can read a french newspaper and that stuff quite well now, but acoustical understanding is still very hard to me [18:26:25] <BastyCDGS> btw, is it safe to set bit_per_coded_sample to 12 (HAM6) resp. to 18 (HAM8)? [18:26:46] <BastyCDGS> because I wouldn't need any extra fields then...I just would have to check in the decoder if it's 12 or 18 [18:27:41] <BastyCDGS> 12 because HAM6 is 4096 color image and 18 because HAM8 is 262144 color image [18:27:53] <BastyCDGS> this way we can still differ from 16 bit images and 24 bit images ;) [18:28:08] <BastyCDGS> but I'm not sure if this breaks something else in ffmpeg [18:28:13] <BBB> no, that should be fine [18:28:20] <BastyCDGS> perfect :D [18:29:00] <BastyCDGS> should I provide here two patches also? one for EHB alone and one for HAM? [18:29:18] <BBB> yes [18:29:21] <jai> if they are independent, then yes [18:29:23] <BBB> because they're completely different things [18:29:44] <BastyCDGS> okey [18:29:49] <BastyCDGS> they are [18:30:52] <BastyCDGS> btw, sometime ago I posted a patch for fixing the IFF reading [18:31:05] <BBB> ping it, I'll review that also now [18:31:06] <BastyCDGS> will this be commited or shall I still change anything there? [18:31:24] <BastyCDGS> wait I'll create a new one with git ;) [18:48:31] <CIA-7> ffmpeg: stefano * r22963 /trunk/libavdevice/v4l2.c: Remove unnecessary width and height variables from v4l2_read_header(). [18:49:55] <BastyCDGS> BBB, just submitted to ml [18:50:14] <BBB> ok [19:03:32] <BastyCDGS> fixed the critics on restruct noindent patch [19:09:41] <BastyCDGS> ooohh, I found a bug... [19:09:54] <BastyCDGS> when displaying an IFF image and you resize the window it goes simply black [19:10:29] <BastyCDGS> is this because the IFF decoder and demuxer doesn't currently using scaling? [19:12:21] <BastyCDGS> just tried out with a jpeg image, same happens there too... [19:15:28] <drv> that's just ffplay + image in general [19:16:17] <BastyCDGS> oh so I shouldn't worry about that in de(muxer|coder)? [19:18:10] <drv> right [19:19:17] <BastyCDGS> then the issue is probably that ffplay doesn't react to window resize messages? [19:21:51] <BBB> it does, but it only updates after the next frame [19:22:03] <BBB> and these videos are 1 frame :) [19:22:38] <BastyCDGS> is a fix appreciated for this? [19:23:27] <wbs> if it's clean and doesn't interfere with anything else, it may be appreciated, I guess that's mostly up to michael [19:31:40] <elenril> BastyCDGS: you should really use git format-patch [19:31:51] <elenril> it includes the commit message into the patch [19:33:37] * Kovensky wonders why does his code fail with mp2 but works with aac [19:34:30] <elenril> Kovensky: witches [19:35:27] <Dark_Shikari> but witches don't exist [19:35:35] <Dark_Shikari> there is no 19th person! [19:36:28] <elenril> got any proof? =p [19:36:50] * elenril wonders why do so many people thinks it's mystery [19:37:39] <Kovensky> oh, got it to work! [19:37:43] <Kovensky> but I had to use a goto D: [19:39:11] <drv> don't worry, raptor-proofing specialists will be at your workstation shortly [19:39:27] <Kovensky> :P [19:39:33] <Kovensky> well, I'm working on getting rid of it [19:39:33] <Kovensky> Decoded 1 [19:39:33] <Kovensky> Decoded 2 [19:39:33] <Kovensky> [mp2 @ 0x60dfd0]Header missing [19:39:33] <Kovensky> lavfsource [error]: error decoding audio [19:39:36] <Kovensky> Decoded 4 [19:39:39] <Kovensky> no idea why mp2 whines about that though [19:39:48] <BastyCDGS> BBB: fixed your issues on my patch [19:39:56] <Kovensky> (the %d are the frame number) [19:40:07] <Kovensky> it then goes without issue until EOF ._. [19:54:42] <BBB> what do you mean "should I change both patches"? [19:54:57] <BBB> submit the case in a separate patch, is what I would say [19:55:04] <BBB> so that the first patch becomes simpler [19:56:15] <wbs> one way of getting rid of all the "how to send proper patches" problems is reading the mailing list for a long time before actually sending anything ;P [19:57:52] <BastyCDGS> I've fixed it...it was already in the other patch [19:57:58] <BastyCDGS> just submitted to ml [20:02:16] <BBB> wbs: I was surprised you never ran into this ;) [20:02:53] <BBB> and now that I work like this, I'm ashamed of earlier patches I've sent to e.g. the linux mailinglist [20:03:01] <BBB> where basically half of my patch was reindenting of a driver [20:03:06] <BBB> and the other half was functional changes [20:03:13] <BBB> nobody could ever have reviewed that AND be sane [20:04:33] <wbs> BBB: i've been subscribed to -devel (and read most mails) for almost a year, and have been browsing the list on and off for quite some time before that, too ;P [20:04:58] <BBB> that's better indeed [20:07:20] <wbs> I ran into some of your past within gstreamer, btw... I had tried making some custom filter using the template perhaps 18 months ago.. now when I looked at the code again, your name is in the copyright list of that template ;P [20:07:32] <BBB> indeed ;) [20:07:50] <BBB> you can go further back, before gstreamer I did mjpegtools and a mjpeg-capture-card linux kernel driver [20:08:06] <BBB> and during gstreamer I did a lot of gnome also [20:08:31] <wbs> ah [20:08:42] <BBB> what do you use gstreamer for? [20:08:46] <BBB> gst-ffmpeg wrapper + filters? [20:09:04] <BastyCDGS> BBB, just read your mail about the 4 more indent [20:09:05] <wbs> nah, interfacing with proprietary codecs and capture devices for work stuff [20:09:07] <BastyCDGS> it seems correct to me [20:09:13] <BastyCDGS> at least in decode_ilbm [20:09:38] <BBB> that might be, I didn't check that very carefully [20:09:44] <BBB> the first one is definitely wrong though :) [20:10:08] <BBB> if you send the cosmetics patch along with it, it becomes easier to check which is wrong and which is right [20:11:09] <BastyCDGS> just compared with original, it's correct [20:11:24] <BastyCDGS> I even copied the original line to new one to compare [20:11:33] <BastyCDGS> the thing is that I removed one if/else completely [20:12:21] <BastyCDGS> or was i looking at wrong pos? [20:12:24] <BBB> maybe [20:13:34] <BastyCDGS> there is only one such a line in decode_frame_ilbm [20:13:59] <BastyCDGS> ohh i think i have it [20:14:34] <BBB> hehe :) [20:21:34] <BastyCDGS> you were correct on both parts but the first one one line was ok [20:21:38] <BastyCDGS> i'll submit to ml now [20:22:43] <BastyCDGS> sent [20:23:24] <BastyCDGS> for doing the remaining indentation it's best way to do a local git commit and then just correct indentation and then git diff right? [20:24:17] <wbs> for indentation stuff, personally i do the changes immediately, but then make patches using git format-patch -w, so that it ignores whitespace changes from the diff [20:25:21] <wbs> but if BBB wants a whitespace-only patch, too, you can e.g. apply the patch from format-patch -w on a separate branch, and diff that against the original branch [20:25:25] <wbs> or something like that ;P [20:25:46] <BastyCDGS> yes that's what he want [20:26:03] <BBB> you can also ask me to do it myself, I tend to not mind so much [20:26:39] * BBB thinks it's funny he responds "okay" but then doesn't actually attached the cosmetics patch ;) [20:28:05] <BastyCDGS> uhh what's wrong, did I miss sth.? [20:30:13] <BBB> no :) you're fine on this one [20:31:14] <BastyCDGS> so both are fine now...fine ;) [20:31:31] <BastyCDGS> then I'll do a local git commit and do the remaining indent stuff [20:31:59] <wbs> BastyCDGS: btw, learn to commit often in git, you're always able to rewrite the commit and change them later [20:32:11] <wbs> instead of working many days on one thing without ever committing inbetween [20:32:37] <BastyCDGS> hmm [20:32:40] <BastyCDGS> basty@cdgs-basty:~/src/ffmpeg$ git commit [20:32:40] <BastyCDGS> # On branch master [20:32:40] <BastyCDGS> # Changed but not updated: [20:32:40] <BastyCDGS> # (use "git add <file>..." to update what will be committed) [20:32:40] <BastyCDGS> # [20:32:41] <BastyCDGS> # modified: libavcodec/iff.c [20:32:41] <BastyCDGS> # modified: libavformat/iff.c [20:32:48] <wbs> please read the fine manual [20:33:31] <BastyCDGS> thought git add is only for new files [20:34:07] <wbs> git has this enormously useful feature called "staging" changes, learn to use it [20:34:35] <BastyCDGS> git commit -a [20:34:39] <BastyCDGS> is the way, right? [20:34:46] <wbs> if that's what you want to do, yes [20:35:13] <wbs> git however gives you the freedom to stage only some of the changes for committing in the current commit [20:35:24] <wbs> for separating logically distinct parts into separate commits [20:36:22] <elenril> read some tutorials at http://git-scm.com/ [20:38:17] <elenril> you'll spend like 20 minutes on one [20:38:31] <elenril> and it'll make everyone's life easier [20:38:37] <elenril> prevent global warming etc [20:39:39] <Kovensky> BastyCDGS: learn to use git gui too, it's very useful for selecting individual lines / chunks to commit [20:39:41] <elenril> btw anyone knows tikz? [20:39:52] <elenril> Kovensky: nah, git add -p is better =p [20:39:58] <elenril> guis are overrated [20:40:17] <BastyCDGS> I successfully were able to commit both libavcodec/iff.c and libavformat/iff.c as separate ;) [20:41:12] <elenril> now you just git format-patch -2 and :magic: [20:50:48] <BBB> BastyCDGS: good work! [20:50:55] <BastyCDGS> so both indent patches done [20:51:11] <BBB> we need someone with channel admin status here [20:51:15] <BBB> I think he needs a voice now [20:51:39] * BastyCDGS searches the unmute button in his face [20:52:21] <BBB> people who have submitted patches which have been accepted in svn/trunk get voice status in the channel, it's a sign of pure awesomeness [20:52:53] <BBB> or something like that [20:52:56] <BastyCDGS> well these patches aren't the first which got into trunk ;) [20:53:10] <BBB> well tell that to the channel admin who didn't know ;) [20:53:22] <BastyCDGS> but thank you very much [20:53:30] <BastyCDGS> what's the difference with a voice status? [20:54:20] <BBB> nothing [20:54:30] <BBB> you get this awesome yellow button in front of your name in xchat [20:54:41] <BBB> that's all :-p [20:54:48] <BastyCDGS> I'm using kvirc not xchat [20:55:12] <iive> you'll also be moved upper in the list, so it would be easy to spot your presence. [20:55:34] <BastyCDGS> ahh now I understand it's these guys listened with a prefixed V icon [20:56:01] <BBB> yes that! [20:56:17] <drv> well, the real purpose of voice is to be able to speak when the channel is +m, but not to have any other permissions [20:56:24] <drv> but usually this channel doesn't get +m anyway [20:58:02] <BastyCDGS> what is the reason here for muting this channel? [20:59:12] <drv> well, it usually never is, that's just a general irc tool [20:59:29] <drv> you can use it for things like a moderated chat with many listeners and a few speakers or something similar [20:59:53] <iive> well, few months ago, muting channel was needed to silence the horde of spam bots [21:00:15] <iive> it took week or two for freenode to roll out the final solution (tm). [21:00:25] <BastyCDGS> damn these fucking spammers [21:00:52] <BastyCDGS> btw, we've forgotten one patch, the minor-op patch...is there anything to do? [21:04:25] <BBB> I haven't reviewed that one yet [21:05:38] <BastyCDGS> mru reviewed it and he didn't found any negative except one indentiation which I should since it's a new line anyway fix with the patch and that I've done [21:05:59] <BastyCDGS> but he didn't reply to the fix, so from his point of view it's probably okay now [21:07:24] <wbs> BastyCDGS: no reply does NOT mean "ok for me" [21:07:47] <BastyCDGS> that's clear but he was complaining just one thing which I've fixed [21:08:11] <wbs> yes, but that does not mean that he's ok with the way that you've solved it, unless he has said "ok if you change it to FOO" or something like that [21:08:45] <wbs> but that's mostly relevant when you've got commit access so that you accidentally could be too triggerhappy and commit stuff before he gets a chance to say something [21:08:52] <BastyCDGS> > + for(i = 0; i < b; i++) { \ [21:08:52] <BastyCDGS> > >> + dst[ i ] |= get_bits1(&gb) << plane; \ [21:08:52] <BastyCDGS> > >> [21:08:52] <BastyCDGS> > [21:08:52] <BastyCDGS> > Since you're anyway rewriting that line, please drop the spaces inside []. [21:08:59] <wbs> ah, well such stuff is trivial [21:09:02] <BBB> ah, mru already said that [21:09:03] <BastyCDGS> that's all he complained ); [21:09:05] <BastyCDGS> ;) [21:09:09] <BBB> I complained about that too just now [21:11:10] <BastyCDGS> but I've tried to apply that patch now and it causes conflicts [21:11:43] <BastyCDGS> is that because I applied it after indentation? [21:13:31] <BastyCDGS> I just compared it and found out that it's exactly the lines where you have been complaining for before I did the indentiation as a second patch ;) [21:13:37] <BastyCDGS> now I finally understand why you want it this way... [21:13:57] <BastyCDGS> it avoids conflicts just because of indentation... [21:14:00] <BastyCDGS> right? [21:24:15] <BBB> yes [21:24:32] <BBB> but it's fine, I'll get them in eventually :) [21:25:02] <BastyCDGS> about the const thing what's exactly your issue there? [21:25:18] <BastyCDGS> b isn't going to be changed ever [21:31:38] <BBB> it's not necessary to mark it const, and I think it's in violation of the C spec to do so [21:31:44] <BBB> the second part is more severe than the first part [21:31:54] <BastyCDGS> why it's a violation of C spec? [21:31:55] <BBB> mru would be able to tell you for sure [21:32:04] <BBB> because it changes if bps/buf_size changes [21:32:06] <BastyCDGS> well, he didn't complain that when he reviewed it ;) [21:32:10] <BBB> const means it never changes :) [21:32:17] <BastyCDGS> but bps/buf_size doesn't change [21:32:23] <BBB> imagine you have a video player that plays video files [21:32:24] <BastyCDGS> only I and dst are changing [21:32:29] <BBB> first it plays one file with bps=X [21:32:32] <BBB> then one with bps=Y [21:32:36] <BBB> bps changed [21:32:46] <BastyCDGS> const means that it's just constant within function scope [21:32:52] <BastyCDGS> or block scope for that matter [21:33:12] <BBB> hmm... mru is that true? [21:33:22] <BBB> of course he went to sleep... [21:33:27] <BastyCDGS> http://tigcc.ticalc.org/doc/keywords.html#const [21:35:34] <BBB> "In this case, the const modifier allows you to assign an initial value to a variable that cannot later be changed by the program" [21:35:40] <BBB> that's ambiguous [21:35:47] <BBB> could be either what you said or what I said :) [21:36:10] <BastyCDGS> please reminder that const unsigned b is just local scope on stack ;) [21:36:18] <BastyCDGS> it will be killed when the function exits [21:36:29] <BastyCDGS> and within this scope it should be const [21:37:23] <BBB> I know, but that doesn't mean it's not in violation of the C spec [21:37:40] <BBB> although gcc doesn't appear to care... [21:37:49] <BastyCDGS> what should be the violation be? [21:37:57] <BBB> we'll have to ask mru tomorrow [21:38:10] <BBB> my personal opinion is that it's not needed, but if he's ok then we'll keep it :) [21:38:29] <BastyCDGS> this one is for me much more likely a violation: [21:38:29] <BastyCDGS> *(int*)&my_age = 35; [21:38:35] <BastyCDGS> when my_age ist const [21:38:39] <BastyCDGS> but I don't use that ;) [21:39:24] <BBB> that's because the (int*) itself is a violation [21:39:32] <BBB> a const int can only be addressed to as const int* [21:39:38] <BastyCDGS> Quoting from the ANSI C standard(8.2), "The purpose of const is to announce objects that may be placed in read-only memory, and perhaps to increase opportunities for optimization. ... Except that it should diagnose explicit attempts to change const objects, a compiler may ignore these qualifiers." [21:39:48] <BastyCDGS> http://www.ae.iitm.ac.in/pipermail/ilugc/2004-August/011781.html [21:40:02] <BBB> again ambiguous, can be either [21:40:04] <BBB> :) [21:40:07] <BBB> wait for mru tomorrow [21:40:23] <BBB> if it's read-only memory, then you have a problem [21:40:31] <BastyCDGS> const on float for example allows the compiler to put the value in the constant fp regs [21:40:32] <BBB> it's not like a static lookup table [21:43:09] <BastyCDGS> here is more detailed info:http://www.ericgiguere.com/articles/ansi-c-summary.html [21:43:13] <BastyCDGS> Special Modifiers [21:43:16] <drv> the compiler can usually prove constness of a local variable anyway [21:44:12] <BBB> gotta go now [21:44:17] <BastyCDGS> Initialization, however, is allowed ;) [21:44:19] <BBB> my recommendation is to remove it ;) [21:44:33] <BBB> because the compiler knows it isn't used in the loop [21:44:34] <BBB> anyway [21:44:35] <BBB> ... [21:44:46] <iive> "expecting gcc to do something right is exception, rather than rule" [21:45:04] <BastyCDGS> yes, it's even such dumb not moving out the calculation [21:45:14] <BastyCDGS> that's why I declared it const [21:45:22] <BastyCDGS> and moved out by hand [21:47:45] <BastyCDGS> well any optimization manual I read so far says that const should always be used when you don't change the variable in its life scope [21:48:05] <BastyCDGS> that's also what my professors say [21:49:00] <BastyCDGS> besides this const increases readibility...that was a huge discussion just recently ;) [21:49:09] <BastyCDGS> it tells the programmer that this variable shouldn't be changed [21:55:45] <BastyCDGS> drv, do you know where in which include lut resides? [21:56:06] <BastyCDGS> v= lut[get_bits(&gb, 4)]; [22:01:22] <drv> which file is it referenced in? if it doesn't have av_/ff_ prefix, it's probably not outside that file [22:02:38] <BastyCDGS> I dunno, Michael Niedermeyer recommended me to use this code to speed up [22:02:40] <drv> ah, i see the mail now, that's probably just michael meaning to create your own lookup table (lut), not an actual name of an existing array [22:03:38] <drv> i would guess since it's 4 bits, just make an array with all 16 possible inputs mapped to their corresponding output [22:04:02] <drv> (i.e. the index is the input and the content of that array location is the output) [22:04:24] <BastyCDGS> what does AV_WN32A and AV_RN32A do? [22:05:34] <drv> write/read 32-bit integer (the A means aligned, i think, and N means native endianness) [22:05:40] <drv> but grep the headers just to be sure :) [22:06:22] <BastyCDGS> #define AV_RNA(s, p) (((const av_alias##s*)(p))->u##s) [22:06:22] <BastyCDGS> s is 32 for WN32A [22:15:58] <BastyCDGS> looks to me that I should do the lookup table the following way [22:16:14] <BastyCDGS> for each set bit do an 1 << plane [22:17:14] <BastyCDGS> 0000 = 0, 0001 = 1 << plane, 0010 = 8 << plane, 0011 = 1 << plane | 8 << plane, etc. [22:21:51] <BastyCDGS> instead 8 = 0x100 sorry [23:36:54] <CIA-7> ffmpeg: stefano * r22964 /trunk/ffprobe.c: [23:36:54] <CIA-7> ffmpeg: Make ffprobe show stream->nb_frames if that info is known. [23:36:54] <CIA-7> ffmpeg: Patch by Robert Kr?ger $(echo kru3g3r(a)signal7.d3 | sed -e 's/3/e/g').

1 0

IRC log for 2010-04-24
by irc＠mansr.com 25 Apr '10

25 Apr '10

[01:36:45] <mru> Dark_Shikari: doubtful [01:36:59] <mru> iphone forces you to do yuv to rgb conversion in software [01:37:06] <mru> even though the hardware is perfectly capable [01:39:33] <RTFM_FTW> umm you don't need to do YUV -> RGB in SW [01:39:48] <RTFM_FTW> you could trivially use the ES1 GL path for this [01:39:56] <RTFM_FTW> which I did :) [01:40:26] <RTFM_FTW> in fact *everything* outside of the initial decode could be handled through 3D HW [01:40:43] <RTFM_FTW> even with fixed function ES1 level HW [01:40:49] <mru> the old iphone has some private apis that let you do it efficiently [01:40:55] <mru> those are gone on 3gs [01:41:09] <mru> and you were never allowed to use them [01:41:11] <RTFM_FTW> again you don't need private APIs either [05:43:05] <Dark_Shikari> mru: so if you had hardware for yuv->rgb [05:43:06] <Dark_Shikari> could you do it? [05:43:10] <Dark_Shikari> i.e. given the lack of simd and all that [05:48:32] * pJok waits for Apple to buy ARM and then pull the IP from the market [05:48:46] <pJok> that would be hillarious [05:49:37] <astrange> RTFM_FTW has done it with gl fixed-function, i haven't seen the video bitrate he used (or how accurate the display was) [05:50:13] <Dark_Shikari> pJok: the merger wouldn't be approved [05:51:36] <pJok> Dark_Shikari, would still be hillarious if it actually would get approved [05:54:02] <pJok> Apple could single handedly ruin ARM [06:02:45] <_av500_> they will also impose lifetime limit on ARM cpus you can buy! [06:03:04] <_av500_> sorry, no more washing machine [06:09:31] <Yuvi> Dark_Shikari: borderline, ffmpeg decodes a 480x320 baseline encoded by x264 --tune fastdecode --subme 0 --bitrate 1500 decodes at 23 fps [06:09:55] <Dark_Shikari> how much do you think could be gained via armv6 asm? [06:11:08] <Dark_Shikari> I've seen SWAR implementations of hpel MC [06:11:08] <Yuvi> no clue, I'd doubt more than 10-20% at the really high end [06:11:25] <Dark_Shikari> well I would assume you could probably double the speed of idct [06:11:32] <Dark_Shikari> and speed up mc copy a lot [06:12:10] <Yuvi> mc 0,0 is already optimized iirc [06:12:15] <Dark_Shikari> ah, true. [06:12:27] <Dark_Shikari> That does seem odd though. 3g is not MASSIVELY slower than 3gs when one ignores lack of neon [06:12:44] <Dark_Shikari> and at subme 0, there's nearly no simd-requiring stuff [06:12:48] <Dark_Shikari> just idct really [06:12:53] <Yuvi> no dual issue, 416 vs. 533 MHz [06:12:59] <Dark_Shikari> oh wow, it's only 416mhz? [06:13:03] <Dark_Shikari> so it's not even a fast arm11 [06:13:55] <Yuvi> or did the 3gs get up to 600 [06:15:28] <Yuvi> internet says it does [06:17:04] <Dark_Shikari> hmm, ok [06:17:21] <Dark_Shikari> maybe if they're interested in optimizing for it, I can get some money =p [06:17:46] <Dark_Shikari> I suspect there may be a lot of opportunities like this in the future, e.g. optimizing for specific hardware targets [06:17:49] <Dark_Shikari> Oh, and they also care about the xbox 360 [06:17:58] <Dark_Shikari> which is apparently too slow to do 720p h264 in a single thread [06:29:51] <pJok> _av500_, i thought washing machines mainly used freescale/nec mcu's or 8051 clones [08:30:36] <_av500_> pJok: not the iWash [08:41:46] <pentanol> hi mru, at this weekend you here? [08:41:50] <pentanol> here kind of tiny ffmpeg http://codepad.org/UXO06Dsq [08:51:37] <pentanol> nop, in first not full, there devided http://codepad.org/ZwudRruj http://codepad.org/Q61vrhyM http://codepad.org/XGz2XvZD [09:05:08] <_av500_> pentanol: your main() does nothing? [09:14:42] <pentanol> no it tries allocate everything necessary... avcodec_alloc_context2 but got a segfault [09:16:06] <_av500_> why are you doing this at all? [09:16:28] <pentanol> perhaps I got this because.... http://codepad.org/00E1U4qK [09:16:43] <pentanol> actually it won't work on my arm uC lib [09:17:05] <pentanol> but it compiled well and then static linked well too [09:19:28] <pentanol> llrint and log does into libm, but compiled doesn't see that [09:27:09] <pentanol> so when I've compiled this static, I obtains http://codepad.org/w6oo0Uu5 [09:31:24] <pentanol> here disasm this elf for arm ... http://download255.mediafire.com/aev5gvpe2YDg/fznjtemntly/ffmpeg_tiny.asm.t… [09:40:04] <pentanol> it crashed everytime when dst= ((uint8_t*)obj) + o->offset; ofset equals 184 [09:57:52] <pentanol> odd it crashes when hits { "iba", 184 } [09:58:21] <mru> pentanol: please try to remove as much as possible [09:58:33] <mru> I expect you to end up with no more than a page [09:58:55] <mru> throw in some printfs so you can trace the code flow [09:58:56] <pentanol> yes, but I can remove [09:59:06] <mru> remove any code that isn't executed before it crashes [09:59:06] <pentanol> because then I can't compiel it [10:15:00] <CIA-7> ffmpeg: stefano * r22958 /trunk/doc/libavfilter.texi: [10:15:00] <CIA-7> ffmpeg: Consistently prefer @var{VAR} over ``VAR'' for indicating filter [10:15:00] <CIA-7> ffmpeg: parameters. [10:40:15] <CIA-7> ffmpeg: stefano * r22959 /trunk/ffserver.c: Statically initialize ffserver.c:config_filename, simplify. [10:40:15] <CIA-7> ffmpeg: stefano * r22960 /trunk/ffserver.c: [10:40:15] <CIA-7> ffmpeg: Implement ffserver.c:report_config_error() and a macro for logging [10:40:15] <CIA-7> ffmpeg: error messages / updating the error count. [10:41:41] <pentanol> mru here disasm and snippet http://download784.mediafire.com/idsqgymgbgTg/yutzmytjodt/ffmpeg_tiny.asm1.… http://codepad.org/VPcbKPYw [11:15:47] <mru> I said you should be able to reduce it to one page of code [12:06:01] <jai> seriously, how many people use ffmpeg on beos? [12:06:06] <jai> i know one :) [12:06:15] * mru knows none [12:06:30] <mru> if mmu_man used it, he'd keep it from breaking [12:06:53] <jai> mmu_man probably has a box somewhere which runs it [12:07:38] <DonDiego> hmm [12:07:45] <DonDiego> fate looks good except for ia64 [12:08:04] <mru> sparc/linux is dead again [12:08:52] <saste> DonDiego: how is the 0.6 release thing going on? [12:10:02] <DonDiego> /misc/samples/mphq/fate-suite/lossless-audio/inside.tta: Operation not permitted [12:10:10] <DonDiego> mru: permission problem on your avr fate box? [12:10:22] <DonDiego> saste: that's what we're talking about right now :) [12:10:34] <DonDiego> bbl [12:13:01] <mru> DonDiego: compiler bug [13:15:45] <pentanol> hm, I got why it segfault happens on my arm, if I delete everything from static const AVOption options[]={ , but leave just one tiny tool works well without segfault [13:44:42] <nfl> DonDiego, I need your public key [13:44:54] <mru> it should be on keyservers [13:45:02] <mru> fingerprint is in MAINTAINERS [14:00:40] <jai> bleh, maybe we can stop using the soc repo ;) [14:01:11] <mru> git ftw [14:01:38] <jai> indeed, and with all those free git services around [14:14:05] <nfl> DonDiego, I've sent you a request for soc repo access [14:21:48] <jai> why not just host your soc code on github? [14:21:54] <jai> nfl: ^ [14:22:23] <merbanan> nfl: if you can provide commit messages to the soc mailinglist you can use whatever you prefer [16:17:22] <RTFM_FTW> astrange I was fooling around with (700k) WMV2 content... [16:18:04] <RTFM_FTW> rendering this into a 5:6:5 display was "meh" concerning quality... 8:8:8:8 (as one would expect) is far better [16:18:22] <RTFM_FTW> its also considerably slower on older (MBX level) HW tho [17:26:37] <_av500_> 565 is meh [17:32:53] <RTFM_FTW> 5:6:5 is ideal when it comes to saving on render bandwidth [17:33:15] <RTFM_FTW> streaming updates (and streaming RTT) aren't cheap operations [17:33:31] <RTFM_FTW> at least on older, highly limited HW [17:47:57] <BBB> did kshishkov come online today? [17:49:29] <janneg> BBB: no, is he supposed to be back? [17:49:35] <BBB> dunno [17:49:40] <BBB> wanted to ask him some vc1-related questions [18:53:21] <twnqx> mh this sucks [18:53:36] <twnqx> uname() is one of the things you can't hook in libc calls? [18:53:56] <twnqx> i hate writing strace() hooks :X [19:51:50] <ShadowJK> I guess the call gets inlined? [20:00:51] <BastyCDGS> good evening to all :) [20:01:45] <jai> twnqx: do you mean ld_preload'ing a custom uname doesn't work? [20:01:56] <twnqx> jai: excatly. [20:02:19] <twnqx> works for programs i compiled here, but not for two commercial apps [20:02:23] <BastyCDGS> puh that was a day today... [20:02:36] <BastyCDGS> had to fix wires from the power supply of my laptop [20:02:55] <BastyCDGS> they were almost broken, but luckily I got fixing it... [20:03:50] <jai> twnqx: what exactly is the error? [20:04:08] <twnqx> sefault. [20:04:11] <twnqx> segfault* [20:04:55] <twnqx> even when i don't touch the values at all [20:05:19] <jai> twnqx: hmm, is libpthread involved [20:05:32] <twnqx> likely [20:05:43] <twnqx> but i don't have local variables, so it would be reentrant [20:05:56] <jai> twnqx: http://sourceware.org/ml/libc-hacker/2010-04/msg00001.html [20:06:16] <jai> could be related [20:06:33] <twnqx> uhhh [20:06:35] <twnqx> hm [20:06:56] <twnqx> could be, if that init is called before i have time to ldopen glibc... [20:07:07] <jai> yes [20:07:10] <jai> exactly [20:07:22] <twnqx> easy to verify [20:07:47] <twnqx> (although my ptrace-based syscall hooker is almost finished now) [20:08:10] <BastyCDGS> btw, I have a strange problem with ffmpeg today... [20:08:16] <BastyCDGS> it doesn't anymore find the IFF loader [20:08:23] <twnqx> but some of the stack unwinds are weird... [20:08:38] <BastyCDGS> even for ASH.LBM it says couldn't find a suitable loader [20:09:44] <BastyCDGS> I try a complete reset, i.e. a clean git checkout again [20:09:45] <twnqx> jai: http://nopaste.info/c79135d39c.html maybe the first is the pthreads one... [20:09:51] <BastyCDGS> maybe I broke something accidentally [20:12:08] <twnqx> though.. maybe my stack unwinder fails [20:12:37] <jai> twnqx: why this whole exercise btw ;) [20:13:05] <twnqx> because the stupid thing refuse to talk to my jtag programmer [20:13:32] <twnqx> Cable operation is not supported when running the 32-bit version of the application on a 64-bit platform. [20:13:32] <jai> oh [20:14:05] <twnqx> hence... *you run on a 32-bit platform* [20:14:19] <twnqx> and i had most of the code around anyway :P [20:14:27] <twnqx> from some... other exercises [20:16:34] <jai> heh [20:16:49] <twnqx> not touched in two years, but even the vdso code is still correctly recognized [20:27:42] <twnqx> jai: you're right [20:27:58] <twnqx> uname is called before i got to load glibc... [20:27:59] <twnqx> hm [20:29:05] <BastyCDGS> does change of the link libs order help here twnqx? [20:29:15] <BastyCDGS> and/or object files? [20:29:48] <twnqx> since the original program isn't by me i can't change :P [20:30:28] <twnqx> hm, calling dlopen() and friends while being called from libpthreads _init seems not to work [20:32:02] <BastyCDGS> does you call it from a launched thread there? [20:32:07] <twnqx> weird, still crashes [20:32:16] <twnqx> ah well [20:32:19] <BastyCDGS> as far as I know you can't call dlopen like stuff from a thread, you have to use main thread [20:32:20] <twnqx> gonna ignore that. [20:32:45] <twnqx> i'm called from libpthreads _init it seems [20:32:51] <twnqx> before pthreads are even started [20:33:08] <twnqx> anyway, the ptrace method is just more code. [20:33:36] <BastyCDGS> had once a similar problem with wxwidgets wanted to open and init a socket from a non-main thread [20:33:41] <jai> twnqx: maybe apply that patch and use that custom glibc build :) [20:33:41] <BastyCDGS> caused all sort of strange stuff [20:34:32] <twnqx> BastyCDGS: i once wrote code that would spawn thrades to asynchronously handle sockets using signals [20:34:46] <twnqx> it was fun to learn how to do that [20:34:49] <BastyCDGS> moving the socket open/init stuff to main thread and then reading/writing socket from the sub-thread then worked well [20:34:52] <twnqx> until someone ran it on debian. [20:35:02] <twnqx> without NPTL. [20:35:17] <twnqx> and you had no ideas which thread would actually receive the signals >_> [20:35:33] <jai> hah! [20:36:55] <BastyCDGS> it's always a good idea to read docs when using multithreaded stuff if the libs you're using are thread-safe... [20:36:58] <jai> twnqx: anyhow, if you have time try the patched build, it should pretty much work [20:37:07] <twnqx> too lazy [20:37:07] <BastyCDGS> there's still many stuff out there which isn't thread-safe [20:37:16] <twnqx> and also, i want it more universal :P [20:37:39] <twnqx> also, i could just implement uname() by reading from /proc, or even by doing the syscall myself [20:38:00] <jai> twnqx: well, the uname call on init should be in glibc's private namespace [20:38:16] <jai> twnqx: but drepper refused it :/ [20:38:23] <twnqx> > drepper [20:39:29] <jai> twnqx: yeah, you'd probably dlsym it from libc, call it, overwrite machine/whatever and returnb [20:39:45] <twnqx> that's what i tried :) [20:40:16] <jai> in an ideal world it would work pretty well too :) [20:40:29] <twnqx> worked for all functions i tried so far :P [20:40:47] <twnqx> uh what [20:40:56] <BastyCDGS> ehm [20:40:57] <twnqx> something's broken now... [20:41:11] <twnqx> when i change it, the app doesn't even start [20:41:14] <BastyCDGS> just was looking your nopaste stuff [20:41:26] <BastyCDGS> it seems you try to call an x86_64 func from x86_32... [20:41:35] <BastyCDGS> that doesn't work without a wrapper, maybe that is the cause? [20:41:38] <twnqx> mh? [20:41:41] <twnqx> nah [20:41:50] <BastyCDGS> http://nopaste.info/c79135d39c.html [20:41:58] <twnqx> it won't preload to a 64bit anyway [20:42:08] <twnqx> itÄs a 32bit lib in that side of the show [20:42:24] <BastyCDGS> uname(): x86_64 from [20:42:35] <BastyCDGS> it seems to call uname x86_64 from a lib32 [20:42:35] <twnqx> yeah.. that's what the kernel replies back [20:43:08] <twnqx> grrr so if i pretend this machine is i686 the app just terminates [20:44:52] <twnqx> so i have to change the reply on a certain call only *sigh* [20:44:56] <jai> twnqx: time for plan b? :) [20:46:34] <twnqx> jai: not yet [20:46:54] <twnqx> does strcpy copy the final 0 as well? [20:47:03] <BastyCDGS> yes [20:47:24] <twnqx> so that's not the mistake. [20:49:15] <BastyCDGS> I think strcpy internally counts number of characters until \0 and then does a memcpy [20:49:45] <twnqx> yeah, quick testprogram confirms correct operation [20:51:56] <jai> BastyCDGS: not the libc implementation atleast [20:52:17] <BastyCDGS> does it call an intrinsic asm func instead? [20:52:26] <BastyCDGS> a rep movsb loop or sth like that? [20:52:43] <jai> BastyCDGS: no, just a plain old do-while [20:53:11] <jai> with some bounds checking on the src pointer after the copy [20:54:07] <BastyCDGS> btw, anyone checked out my optimization link from yesterday [20:54:18] <BastyCDGS> this guy has very optimized memcpy, strcpy, malloc, etc. stuff [20:54:23] <BastyCDGS> malloc uses mem pooling etc. [20:54:28] <BastyCDGS> might be of interest for ffmpeg ;) [20:56:28] <BastyCDGS> twqnx, could you explain me a bit what you want to do with uname anyway? [20:56:35] <BastyCDGS> I did miss the start of your discussion [20:56:44] <twnqx> i want the program to believe it runs on i686 [20:56:54] <twnqx> (it's a 32bit app anyway) [20:57:01] <BastyCDGS> why that is necessary? [20:57:22] <twnqx> it refuses to what it is supposed to on x86_64 [20:57:56] <twnqx> and the culplrit why it's not working... is apparently the compat libx11 [20:58:12] <twnqx> so... i need to modify my stack unwinder [20:58:16] <twnqx> sucks. [20:58:39] <BastyCDGS> what does your stack unwinder do exactly? [20:58:56] <twnqx> figure out from where the calls originate [20:58:59] <BastyCDGS> I assume you're dealing with plain C in the whole space? [20:59:07] <twnqx> ummmm... [20:59:20] <BastyCDGS> if there's C++ involved you have also to unwind exceptions [20:59:27] <twnqx> ah that you mean [20:59:35] <twnqx> i don't really care [20:59:52] <twnqx> but C++ might explain the [stack] hops [21:00:00] <twnqx> in the backtraces on the pastebin [21:00:11] <BastyCDGS> exceptions have to be unwinded even if you don't use them [21:00:26] <twnqx> i'm unwinding from an assembler perspective [21:00:39] <twnqx> i don't care where it jumped true [21:00:42] <twnqx> through* [21:01:02] <twnqx> i gues longjmp() would break it [21:01:13] <BastyCDGS> that's possible, too. [21:01:21] <twnqx> exceptions shouldn't [21:01:34] <twnqx> it just reads the stack [21:02:22] <BastyCDGS> not 100% sure about this if exceptions are also on the stack, if in doubt try the C++ stuff compile with -fno-exceptions -fno-rtti [21:02:36] <twnqx> i can't compile this [21:02:41] <BastyCDGS> oh [21:02:43] <twnqx> if i could compile it [21:02:44] <BastyCDGS> closed source? [21:02:58] <twnqx> why else would i try to modify the behavior from the outside... [21:03:34] <BastyCDGS> that's right...but could be a learning exercise ;) [21:04:26] <twnqx> it for sure contains Cüü [21:04:28] <twnqx> C++ [21:04:39] <twnqx> since it has libQt and friends [21:04:53] <BastyCDGS> if it uses Qt then it's 100% C++ ;) [21:05:23] <BastyCDGS> maybe you find some infos regarding this with a hexdump of the executable [21:05:33] <twnqx> boring [21:05:33] <BastyCDGS> a lot of compilers put their signature there [21:05:42] <twnqx> i have no intention of even looking at it [21:05:50] <twnqx> i just want it to work :P [21:05:54] <BastyCDGS> if they compiled with exceptions you have to deal with them I'm afraid off [21:06:05] <twnqx> shouldn't matter at all [21:06:12] <twnqx> they'll just be on the stack [21:07:32] <BastyCDGS> I'll do a search on this one moment [21:10:16] <BastyCDGS> the thing is that you can't mix code with -fno-exceptions and code with -fexceptions [21:10:22] <BastyCDGS> even within g++ [21:10:32] <BastyCDGS> so they both interfere somehow [21:11:41] <BastyCDGS> maybe the compiled code also uses -ffast-call [21:12:06] <BastyCDGS> which pushes first two function args in regs instead on stack on x86_32 [21:13:22] <BastyCDGS> http://stackoverflow.com/questions/490773/how-is-the-c-exception-handling-r… [21:14:32] <BastyCDGS> btw, another idea to solve your problem [21:14:48] <BastyCDGS> do you have an x86_64 with virtualization support (patricia etc.)? [21:15:01] <BastyCDGS> maybe you can use this to make your app thinking it's a x86_32 [21:15:35] <BastyCDGS> this even allows faking CPUID to return a different string [21:15:40] <BastyCDGS> vendor id etc. [21:17:42] <twnqx> hm [21:17:54] <twnqx> i wonder if it *does* cpuid [21:18:03] <twnqx> where's my single stepper... [21:19:14] <BastyCDGS> btw, just looking at your nopaste stuff again, I see 4x [stack] instead of a func name [21:19:22] <BastyCDGS> this could be the exception stuff [21:20:20] <BastyCDGS> at least try to find out which compiler they we're using... [21:21:03] <BastyCDGS> btw, if you're single stepping find the position where it wants to call uname and replace this with a series of NOPs ;) [21:32:11] <twnqx> i could just dynamically scan the program's memory for the x86_64 string and replace it with x86_65 [21:33:06] <BastyCDGS> would be possible, too... [21:34:42] <BastyCDGS> don't forget that the string might be wchar_t [21:35:10] <BastyCDGS> to check for x\08\06\0_\06\04 [21:35:12] <BastyCDGS> so [21:42:11] <twnqx> processtools.c:170: error: generating trampoline in object (requires executable stack) [21:42:12] <twnqx> O_O [21:42:25] <twnqx> now that's a gcc error i never saw before [21:42:39] <BastyCDGS> I see this error now for the 1st time, too ;) [21:42:56] <BastyCDGS> what did you change that this error occurs? [21:43:37] <twnqx> i... moved a function which is a parameter for another function into a third function [21:44:13] <twnqx> http://nopaste.info/0f3e44a760.html [21:46:16] <BastyCDGS> hmm if remembering correct you can't do this... [21:47:01] <twnqx> oh, you can [21:47:07] <twnqx> just not with -Wall -Werror :P [21:48:38] <BastyCDGS> I mean it violates the standard and it seems that gcc gets confused when you do it anyway [21:49:09] <twnqx> processtools.c:170: warning: generating trampoline in object (requires executable stack) - jo it just generates a trampoline (and a warning) [21:49:47] <BastyCDGS> is there any specific reason you want it inside a function? [21:50:09] <twnqx> i want another version of it that needs access to the outer function's parameters [21:50:54] <BastyCDGS> and this really works this way? [21:51:12] <BastyCDGS> why not use just global vars for testing? [21:51:32] <twnqx> because then i have globals vars in the final too :( [21:51:45] <twnqx> and yes, works. [21:52:20] <twnqx> i could just pass a void pointer to the unwind, and make it pass the same to the callback [22:08:46] <twnqx> wow, changing the return "sometimes" causes heisenbugs [22:09:12] <BastyCDGS> quantum physics bugs :D [22:09:23] <twnqx> i just had a heap corruption [22:10:19] <BastyCDGS> btw, there is a language out here which mimics QM that means the code does change by random factors and thus does everything sth. else [22:10:58] <twnqx> hm i wonder how making a child sleep via ptrace and threads interact [22:11:37] <BastyCDGS> you mean sending/receiving signal messages? [22:11:53] <twnqx> well... blocking it on syscall [22:13:43] <BastyCDGS> http://kerneltrap.org/index.php?q=mailarchive/freebsd-hackers/2007/3/31/219… [22:13:54] <BastyCDGS> look at the post from w0rm [22:29:05] <twnqx> meh [22:30:42] <BastyCDGS> did that help a bit? [22:34:54] <twnqx> not yet [22:35:52] <twnqx> i just realized that the application apparently loads more libs during runtime [22:36:40] <twnqx> and possibly doesn't use the uname output at all [22:37:39] <BastyCDGS> so CPUID? [22:38:24] <BastyCDGS> maybe it's really the best way to use the newer CPU virtualization functions to get this working [22:38:33] <twnqx> it even opens the library that has the error messgae dialog only after the tenth or so uname call [22:38:45] <BastyCDGS> I have no experience regarding coding this but maybe a look into VirtualBox src helps a bit [22:38:48] <BastyCDGS> qemu [22:52:30] <twnqx> funny [22:52:34] <twnqx> in console mode it works [22:52:46] <twnqx> OS platform = i686. [22:52:46] <twnqx> # [22:53:06] <twnqx> so yeah, it uses uname, and if you change it, sometimes it crashes. [22:53:33] <twnqx> tha wouldn't all be so bad [22:53:37] <BastyCDGS> sometimes? that means it basically works with x86_64? [22:54:02] <twnqx> it totally works with x86_64, just actively denies me the functionality i want [22:54:24] <BastyCDGS> why did they implement then such a silly thing? if it works? [22:54:30] <twnqx> well [22:54:36] <twnqx> dunno it it works (yet) [22:54:37] <BastyCDGS> do they want you buying an extra license for 64 bit? [22:54:44] <twnqx> there's one thing: [22:54:56] <twnqx> ERROR:iMPACT - Please update to WinDriver version 8.02 or later. See Answer Record 22648. [22:55:02] <twnqx> (i am running version 10.1) [22:55:05] <twnqx> <_< [22:55:30] <twnqx> because the version they ship [22:55:35] <twnqx> does not compile on 2.6.33 [22:55:49] <BastyCDGS> WinDriver??? [22:55:51] <twnqx> actually, even 10.1 doesn't [22:56:07] <twnqx> unless you modify it slightly (just some checks for includes that moved around) [22:56:35] <BastyCDGS> does it use windows drivers? [22:56:40] <twnqx> apparently some kind of multi-os HAL [22:57:05] <twnqx> i just had to totally rewrite their utterly wrong udev rules file [22:57:28] <twnqx> now... [22:57:43] <BastyCDGS> seems these guys have programmers there that just are able to install sth. like ubuntu ;) [22:57:51] <twnqx> no [22:57:58] <twnqx> sles. [22:58:09] <twnqx> 9.0 it seems [22:58:18] <twnqx> fuck it was more than painful on windows [22:58:29] <twnqx> because the same bullshit checks exist "do not install on 64bit" [22:58:44] <twnqx> then you run it in virtual xp mode (effectively a VM) [22:58:56] <BastyCDGS> win7 virtual xp mode? [22:58:56] <twnqx> and it doesn't work because "can't run in terminal server" [22:58:59] <twnqx> yes [22:59:20] <twnqx> so you can't run the app window only, but if you use the FULL VIRTUALIZED version it works [23:00:35] <BastyCDGS> M$ could start with releasing only 64-bit versions of newer windows versions...I bet in just one week there's no x86_32 only software anymore ;) [23:02:12] <twnqx> the funny thing is [23:02:28] <twnqx> after it detects this driver [23:02:51] <twnqx> and fails to use it because the latest version that is newer tahn the minimum is too old [23:03:00] <twnqx> it recognizes x86_64 again [23:04:52] <BastyCDGS> strange piece of software, really... [23:05:43] <BastyCDGS> but what's the purpose of this tool after all? [23:05:47] <BastyCDGS> what do you use it for? [23:06:45] <twnqx> program the effing FPGAs from that vendor [23:06:52] <twnqx> and [23:06:56] <twnqx> i feel [23:07:04] <twnqx> kinda annoyed, lookinf into my dmesg [23:07:53] <twnqx> the crashes of this program, when i change the name [23:07:57] <twnqx> of the machine [23:08:04] <twnqx> segfault at 6d7c6d60 ip 000000006d7c6d60 sp 00000000ffeb6a0c error 14 in libnss_nis-2.11.so[f4d45000+9000] [23:08:18] <twnqx> it crashes mostly... in libnss_nis [23:08:32] <twnqx> also in libcups, or libXipc [23:08:46] <BastyCDGS> does it call lib32 versions of it? [23:08:50] <twnqx> has to [23:08:54] <twnqx> it's all 32bit [23:09:06] <twnqx> segfault at 56f556e1 ip 0000000056f556e1 sp 00000000ffeea2ec error 14 in 87f5e051180a7a75f16eb6fe7dbd3749-le32d4.cache-3[f4eeb000+6000] [23:09:14] <twnqx> do i even want to know what it's doing... [23:09:55] <BastyCDGS> ehm the stackpointer has an odd address [23:10:03] <BastyCDGS> .....e1 [23:10:10] <twnqx> that's eip [23:10:18] <BastyCDGS> oops right [23:10:42] <twnqx> i BET their sizeof (struct utsname) differs from mine [23:11:04] <BastyCDGS> probably due to alignment rules then [23:11:08] <twnqx> and i'm overwriting their stack [23:11:19] <twnqx> no, because that struct is chaos [23:11:41] <twnqx> let's see what happens with more precide poking [23:16:57] <twnqx> yes. of course. that was the cause of all the crashes. [23:17:00] <twnqx> >_> [23:17:17] * twnqx goes mad [23:18:26] <BastyCDGS> 64-bit aligns different than 32-bit [23:18:31] <twnqx> no [23:18:36] <twnqx> the whole code runs in 32bit [23:18:38] <twnqx> but [23:18:52] <twnqx> there's an extension in gnu mode [23:18:57] <twnqx> a fifth string [23:19:08] <twnqx> i did not set gnu mode [23:19:41] <twnqx> however, instead of grabbing the whole struct from the process' memory, modifying 5 bytes, and writing all of it back [23:19:53] <twnqx> only writing the 5 bytes back makes it very well behaving. [23:20:27] <BastyCDGS> that means much less crashes now? [23:20:39] <twnqx> no crashes. [23:21:34] <twnqx> good, i managed to solve 4 problems in getting this app to work so far [23:21:34] <twnqx> >_> [23:21:55] <BastyCDGS> that's fine... [23:22:06] <twnqx> now for the last [23:22:07] <BastyCDGS> hope that my assists helped you a bit though [23:22:18] <twnqx> a version issue between two binary blobs [23:33:21] <BastyCDGS> I'll go to bed now, very tired now [23:33:39] <BastyCDGS> i wish you a good night and nice dreams and much success with fixing the last issue ;) [23:55:24] <Dark_Shikari> how do I view the kernel syslog?

1 0

IRC log for 2010-04-23
by irc＠mansr.com 24 Apr '10

24 Apr '10

[01:19:52] <Dark_Shikari> we just had the first bug report on win64 due to an application not saving the callee-save xmm registers [01:20:07] <Dark_Shikari> a data value that *was* 0 got changed to "not 0" by an external lib [01:20:14] <Dark_Shikari> Probably Avisynth or ffmpeg via Avisynth. [01:20:43] <Dark_Shikari> Given how much of a bitch this was to track down, I would like: [01:21:01] <Dark_Shikari> Either 1) Drop ffmpeg win64 support until it actually works. The fact that it even configures to build is wrong. [01:21:06] <Dark_Shikari> or 2) fix the bloody thing [01:21:24] <mru> you know what 2 entails [01:21:56] <Dark_Shikari> it means adding a few xmm clobbers [01:22:07] <Dark_Shikari> we can do #define WIN64_CLOBBERS [01:22:13] <Dark_Shikari> and define it to nothing if it isn't win64 [01:22:21] <Dark_Shikari> and define it to the xmm clobbers if it is [01:22:25] <mru> does it hurt to always mark them? [01:22:26] <Dark_Shikari> or whatever. [01:22:30] <Dark_Shikari> .... probably [01:22:38] <Dark_Shikari> The vast majority of asm doesn't use any more than the standard 8 xmm regs though [01:22:48] <Dark_Shikari> thus a max of two to mark [01:22:58] <mru> I mean does it hurt to mark as clobbered the regs that actually are clobbered? [01:23:10] <Dark_Shikari> I doubt it, it just forces gcc to save them [01:23:20] <Dark_Shikari> which obviously hurts speed a bit, but that's required by the abi [01:23:26] <mru> will gcc save them even if it wasn't using them? [01:23:37] <mru> on linux [01:23:40] <Yuvi> it shouldn't on non-win64 abis [01:23:48] <Yuvi> (not actually tested) [01:23:48] <Dark_Shikari> oh, true, you're saying we could _always_ set them on clobber [01:23:50] <mru> shouldn't != doesn't [01:24:00] <Dark_Shikari> yeah, that could work. [01:24:13] <mru> if the code does clobber them, it should say so [01:24:19] <Dark_Shikari> either way, imo we should drop it right now from configure [01:24:20] <mru> anything else is a dangerous gamble [01:24:24] <Dark_Shikari> it would give people an incentive to fix it [01:24:35] <Dark_Shikari> rather than currently where we pretend that it works when it doesn't [01:27:55] <mru> how hard is it to find the places that need fixing? [01:29:11] <Dark_Shikari> every block of sse asm in ffmpeg [01:29:13] <Dark_Shikari> grep "xmm" [01:30:54] <Dark_Shikari> well, I got ramiro to drop 64-bit builds [01:32:08] <mru> 1275 lines containing %%xmm [01:32:58] <Dark_Shikari> Have fun :) [01:41:16] <bcoudurier> is there any way to get more precision that ms in matroska ? [01:42:44] <bcoudurier> I'm not sure I understand the code [01:43:32] <Yuvi> bcoudurier: matroska has a fixed timebase of x/1e9 [01:44:05] <Yuvi> so you could set it to something else, but I don't see much point since it's very unlikely to be accurate anyway [01:46:36] <bcoudurier> so how come our demuxer output ms timestamps ? [01:47:05] <Yuvi> oh, basically all mkv files in existence use 1/1000 as the timebase [01:47:20] <Yuvi> thought you were asking about creating them [01:47:27] <Yuvi> and yes, only one timebase per file [01:51:30] <bcoudurier> that's is crappy [01:51:41] <bcoudurier> using ms is very bad for audio [01:52:18] <bcoudurier> anyway, the more I understand mkv the less I understand why people use it [01:52:36] <Yuvi> mkvmerge [01:52:40] <Yuvi> that's pretty much it [01:52:55] <mru> it existed at the right time [01:53:00] <Yuvi> that too [01:53:17] <bcoudurier> we really missed an opportunity [01:53:19] <mru> avi was dead, and there wasn't much else [01:53:30] <bcoudurier> too bad I wasn't knowing shit about video at that time [01:53:37] <mru> for a while people were messing with ogm [01:53:42] <mru> thankfully they gave up on that [01:54:13] <bcoudurier> what's the biggest shortcoming of mkv in terms of usage/features [01:54:29] <mru> it's too fucking complicated [01:54:37] <mru> there are three ways of doing everything [01:55:47] <bcoudurier> well the user doesn't know about that, there are good tools [01:56:17] <Yuvi> in terms of implementations, probably that most demuxers can't seek without an index [02:01:57] <bcoudurier> humm audacity stalls for like 30 secs when loading a 40 min wav file [02:02:06] <bcoudurier> good job guys [02:03:30] <peloverde> audacity is bit of a mess [02:09:35] <Dark_Shikari> bcoudurier: the reason is simple: good tools, good support for the formats people wanted to use [02:09:44] <Dark_Shikari> at the right time. [02:10:33] <bcoudurier> ah, peloverde, how are you ? could you please tell me what channel layout aac use by default ? [02:11:04] <Yuvi> hm, apparently {} means something weird by default in inline asm [02:11:15] <mru> hmm? [02:11:21] <Yuvi> http://llvm.org/bugs/show_bug.cgi?id=6780 [02:12:11] <Yuvi> xadd{l} and {%0,%1|%1,%0} [02:12:29] <peloverde> The decoder exports channels in SMPTE order I think [02:13:47] <mru> Yuvi: I've never seen such syntax before [02:13:47] <peloverde> Internally it is C L R SL SR LFE [02:15:47] <Yuvi> undocumented gcc fun! [02:32:57] <bcoudurier> that would be MPEG [02:33:19] <bcoudurier> SMPTE is L R C LFE Ls Rs [02:46:06] <peloverde> That's why I said exports vs internally [02:52:15] <bcoudurier> oh right, sorry I'm tired [03:05:16] <Yuvi> mru: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43862 <- llvm gets them all except smulwb/smlawb [06:37:02] <wbs> superdump: what's an AMR-NB decoder supposed to output when given DTX/SID frames, or when given "no data" frames? [06:37:23] <wbs> superdump: I managed to produce such samples recently, and noticed that the lavc decoder doesn't support them [06:37:42] <wbs> opencore seems to output more or less plain zero when given such frames [06:38:22] <wbs> with a few samples slightly off (most samples being 0, some samples being -8) [06:38:24] <superdump> i'm not sure off the top of my head what a DTX frame is [06:38:30] <superdump> but a SID frame is silence iirc [06:38:44] <superdump> it'll be in the specs somewhere [06:38:52] <wbs> I think DTX == SID, just different naming [06:39:14] <superdump> http://www.3gpp.org/ftp/Specs/html-info/26-series.htm [06:39:19] <superdump> amr-nb specs are there [06:39:31] <superdump> http://www.3gpp.org/ftp/Specs/html-info/26090.htm [06:39:37] <superdump> should be detailed in that document i think [06:39:44] <wbs> ok, I'll have a look [06:39:53] <superdump> patches welcome :) [06:40:19] <wbs> if it's plain silence, it's interesting that there's both the SID frames that have a few bytes data, and the "no data" frames that have no data at all [06:41:04] <superdump> it may be that it's easier to restart the stream from SID than from nothing [06:42:39] <wbs> hmm, maybe [07:05:42] <wbs> wonderful standard, there's only four different kinds of comfort noise frames ;P [07:33:54] <CIA-7> ffmpeg: michael * r22951 /trunk/libavutil/log.c: [07:33:54] <CIA-7> ffmpeg: Reenable ANSI colors, use method from VLC as suggested by ramiro. [07:33:54] <CIA-7> ffmpeg: Please tell us asap if this breaks for your platform & terminal. [08:12:42] <CIA-7> ffmpeg: michael * r22952 /trunk/libavutil/log.c: Merge the 2 ANSI ESC codes. [10:43:48] <bilboed-pi> KotH, was wondering, is there a history of changes done to the samples repository ? [10:43:54] <bilboed-pi> KotH, like when files were added/removed [10:44:43] <mru> afraid not [10:46:27] <av500> put them in svn [10:46:42] <bilboed-pi> ITYM git [10:46:46] <bilboed-pi> :) [10:46:48] <av500> or put allsamples.txt in svn [10:46:59] <bilboed-pi> oh well... no biggie [10:47:07] <av500> run it once a day, if there is a diff, commit [10:47:14] <bilboed-pi> just need to figure out if there's a "don't delete locally" flag for rsync [10:49:48] <av500> grah, ffmpeg still refuses to mux mkv into anything [10:52:42] <Dark_Shikari> mru: poke [10:52:47] <Dark_Shikari> I have a company that wants ffmpeg running faster on iphone [10:52:51] <Dark_Shikari> and has money [10:52:55] <mru> gimme [10:53:09] <mru> doing what on iphone btw? [10:53:14] <mru> decode? encode? [10:53:22] <Dark_Shikari> decode h264 [10:53:32] <mru> there's not much more I can do there [10:53:37] <mru> a few % [10:54:10] <Dark_Shikari> give me that configure command with standard neon options or whatever [10:54:15] <Dark_Shikari> apparently they forgot asm on their 3GS bulid (neon) [10:54:23] <Dark_Shikari> I can't be sure, but given their numbers it is nigh-certain [10:54:47] <mru> search the ml [10:54:53] <mru> I don't remember the apple magic [10:54:59] <Dark_Shikari> I don't mean the apple magic [10:55:01] <Dark_Shikari> just give me your baseline on [10:55:03] <Dark_Shikari> *one [10:55:07] <Dark_Shikari> and I can make them responsible for the apple magic [10:55:13] <Dark_Shikari> too bad yuvi just left [10:55:13] <mru> it mgiht be different for apple [10:55:42] <av500> --tree-fruit? [11:00:28] <mru> Dark_Shikari: fate should have good configure commands [11:01:43] <KotH> bilboed-pi: rsync doesn't delete any local files unless you tell it to do so [11:01:51] <KotH> bilboed-pi: it might overwrite files though [11:02:09] <bilboed-pi> KotH, thx [11:06:36] <Dark_Shikari> mru: Samsung is fucking with us [11:06:41] <Dark_Shikari> one of the proposals in their latest round of JVT stuff [11:06:42] <Dark_Shikari> Color Component correlation based prediction (CCCP) [11:06:54] <mru> lol [11:07:23] <mru> didn't know the koreans has such sense of humour [11:07:25] <mru> it's not like them [11:08:02] <Dark_Shikari> BBC and Samsung joint proposal [11:08:05] <Dark_Shikari> brits and koreans [11:08:13] <Dark_Shikari> Also, that is my favorite feature in their proposal [11:08:17] <Dark_Shikari> it predicts chroma based on luma [11:08:31] <mru> ah, I'd expect something like that from the brits [11:08:57] <mru> do you have a name of the bbc rep? [11:10:26] <Dark_Shikari> Ken McCann [11:15:44] <mru> don't know him [11:16:05] <av500> http://www.zetacast.com/Zeta_About_Us.htm [11:17:47] <mru> zeta, isn't that that greek letter that's impossible to write? [11:18:29] <av500> ζ [11:18:46] <mru> yeah, that one [11:19:03] <Dark_Shikari> http://ftp3.itu.ch/av-arch/jctvc-site/2010_04_A_Dresden/ [11:19:09] <Dark_Shikari> all the A100+ ones are full spec rewrite proposals [11:19:15] <Dark_Shikari> A124 in particular is the most interesting [11:19:21] <Dark_Shikari> it achieves 40%+ compression improvement over h264 [11:19:29] <av500> at what price? [11:19:34] <Dark_Shikari> Though hopefully someone will smack them upside the head for the 12-tap interpolation filter [11:19:37] <Dark_Shikari> which I think is wholly unnecessary [11:19:38] <mru> 5 billion patents [11:19:46] <Dark_Shikari> it's the BBC / samsung proposal [11:19:48] <mru> 12-tap... omg [11:19:59] * mru wants wider simd... [11:20:14] <av500> Thomas Davies (BBC) [11:20:40] <Dark_Shikari> it has new transforms up to like 64x64 [11:20:48] <Dark_Shikari> that combine wavelet/dct to allow it to be done in 16-bit precision [11:20:54] <av500> but it still loses to VP9... [11:20:55] <Dark_Shikari> rotational transforms [11:20:56] <mru> is this h265 work? [11:20:58] <Dark_Shikari> yes [11:21:29] <mru> I heard they're going for larger block sizes [11:21:31] <mru> makes sense [11:21:49] <mru> and I bet MVs can be more than 16 pixels :-) [11:23:17] <av500> 1/12 pel accuracy [11:23:46] <Dark_Shikari> implementing all this in hardware is going to be funny [11:24:10] <mru> I'm sure they're thinking of that [11:24:14] <mru> they usually do [11:24:34] <Dark_Shikari> Some of the proposals seem to be more hardware-minded than others. [11:24:41] <Dark_Shikari> Mediatek's is, incredibly unsurprisingly. [11:24:42] <mru> h264 is full of stuff that just fits in 16-bit arithmetic [11:26:19] <av500> Average decoding time about 2.4 times that of JM17.0 [11:26:44] <av500> Dark_Shikari: I am sure they are all thinking about hw implementations [11:27:22] <Dark_Shikari> of course, they're comparing _without SIMD_ [11:27:30] <Dark_Shikari> which is a serious problem especially when consdiering hard-to-simd things [11:27:38] <Dark_Shikari> And we don't know how much they optimized their decoder. [11:27:42] <Dark_Shikari> That's the big thing I worry about [11:27:59] <Dark_Shikari> since this _is_ a competition, there's huge incentive to optimize your decoder to make it appear to be lower complexity [11:28:34] <av500> Dark_Shikari: but seriously, who will decode H265 HD in SW? [11:28:44] <twnqx> my laptop will! [11:28:48] <Dark_Shikari> av500: everyone [11:29:03] <Dark_Shikari> For the 3 years it takes to design and tape out efficient HW [11:29:05] <av500> my PC -> GPU -> HW [11:29:11] <av500> my phone -> HW [11:29:11] <Dark_Shikari> Your GPU doesn't support H.265. [11:29:15] <av500> my TV -> HW [11:29:15] <Dark_Shikari> Your phone doesn't support H.265. [11:29:19] <Dark_Shikari> Your TV doesn't support H.265. [11:29:24] <av500> of course [11:29:50] <av500> but that does not matter for the great unwashed [11:30:02] <Dark_Shikari> er... their stuff doesn't support it either. [11:30:04] * KotH puts av500 into bathtub [11:30:19] <av500> KotH: is it not sunday yet! [11:31:36] <av500> Dark_Shikari: true, my TV does not support H265, but it did not suport H264 as a SW backport either [11:31:48] <av500> it did when it got a HW decoder [11:31:54] <av500> aka a new tv [11:32:10] <Dark_Shikari> yes... which will take a long time [11:32:20] <Dark_Shikari> not only do people have to upgrade their TVs, but they have to actually make the hardware [11:32:25] <av500> sure [11:32:25] <Dark_Shikari> and making the hardware takes much longer than making software [11:32:31] <av500> same for bluray/h264 pickup [11:32:41] <Dark_Shikari> and since when do TVs decode video? [11:32:44] <Dark_Shikari> they use STBs for tat [11:32:49] <Dark_Shikari> *that [11:32:50] <av500> same thing [11:32:57] <Dark_Shikari> Not really, there's a big difference [11:33:01] <Dark_Shikari> STBs get replaced when Comcast wants to. [11:33:07] <Dark_Shikari> TVs get replaced when the consumer wants to. [11:33:13] <av500> not here [11:33:30] <av500> but anyway [11:33:35] <av500> thats not the point I think [11:33:48] <av500> for STB its even easier to roll out new HW... [11:34:09] <mru> directv in the US have something like 20M STBs in the field that can't even decode h264 [11:34:25] <mru> they're not replacing them until they fail [11:34:41] <av500> mru: right, so they do not care for a super effiecient H264 SW decoder [11:34:55] <av500> coz it would have to decode HD on SD hardware [11:35:10] <av500> its not about 10% [11:35:16] <mru> this things have puny 100MHz CPUs [11:35:19] <mru> if you're lucky [11:35:30] <mru> 54MHz used to be common [11:35:32] <mru> 2*27 [11:35:37] <av500> I know [11:35:48] <av500> so the bump in codec caps is by adding new HW [11:35:53] <Dark_Shikari> av500: also, complexity matters for hardware as well... [11:35:59] <av500> not by a SW update [11:36:03] <Dark_Shikari> high complexity -> you can't make a DSP implementation for many years [11:36:08] <Dark_Shikari> No DSP implementation -> you need an ASIC implementation [11:36:09] <av500> Dark_Shikari: yes, but as you pointed out, the numbers are simdless [11:36:18] <mru> the newer STBs are all programmable [11:36:18] <Dark_Shikari> you need an ASIC implementation -> higher dev times [11:36:25] <av500> so they do not relate to HW [11:36:26] <Dark_Shikari> av500: yes, which means it's _worse_ than the numbers show [11:36:31] <mru> DSP + programmable accelerators [11:36:45] <av500> mru: I know the tech details [11:36:55] <Dark_Shikari> the main problem I see is just too much _shit_ [11:37:08] <Dark_Shikari> hundreds of intra modes, dozens of different transforms [11:37:10] <Dark_Shikari> this is stupid. [11:37:11] <mru> it's still early stages [11:37:17] <Dark_Shikari> Yeah, I know, they will pare it down [11:37:18] <mru> everybody is tossing ideas in the pot [11:37:27] <Dark_Shikari> I'm just saying that some of the current proposals are a bit... insane [11:37:30] <mru> patented ideas of course [11:37:55] <av500> Dark_Shikari: i dont understand why dont they just standardize a VM, then you download the decoder in the bitstream :) [11:38:02] <mru> they'll end up with a spec where all the members get a few patents included [11:38:58] <av500> once the "tools" are turing complete, anything goes [11:43:18] <mru> btw, ffmpeg is accepted for linuxtag [11:43:26] <av500> \\\ooo/// [11:43:48] <av500> which means I need to find a way to get the beast to berlin..... :( [11:44:37] <KotH> so is mplayer and ogp [11:44:58] <mru> how's the BBB render doing? [11:45:16] <av500> http://www.jannau.net/bbb_videowall/ [11:45:18] <av500> look good [11:45:18] <mru> I "fixed" my c2q [11:45:27] <mru> but it crashed compiling a kernel [11:45:32] <mru> something's unstable [11:45:43] <KotH> doesnt look too bad imho [11:46:03] <av500> frak this linuxtag is 3 working days [11:46:11] <mru> always is [11:46:36] <KotH> it used to be 4 [11:46:37] <mru> we could sneak in a little message from our sponsors, if that makes your boss happy [11:46:38] <av500> i dont think I can stay the whole time [11:46:46] <mru> KotH: 3 working days + saturday [11:46:54] <KotH> ah.. [11:46:57] * KotH doesnt read [11:47:02] * KotH cant type [11:47:12] <KotH> it's somehow not my day today [11:47:15] * KotH blames spaam [11:47:24] <av500> ok, drink night is thursday [11:48:26] <mru> if we ask around we can probably find someone who can bring the beast to berlin [11:48:45] <av500> mru: yeah, if I go to droidcon in may, i can prolly bring it to janneg [11:51:04] <av500> or you will have to pick it up here :) [11:51:53] <janneg> rendering is a little bit unpredictable. KotH's machine is working on a single take since the 3rd with 8-9 hours per frame [11:52:13] <mru> av500: we have people in that area [11:52:19] <av500> i know [11:52:48] <KotH> janneg: wtf? [11:52:53] <Dark_Shikari> btw, I have an image of the first fully compliant open source-compressed blu-ray disk [11:52:58] <Dark_Shikari> I wonder if you can distribute copies of that there =p [11:53:00] <janneg> OTOH we have enough material and could just switch to the HD scenes [11:53:16] <mru> Dark_Shikari: where can I grab a copy? [11:53:20] <av500> url? [11:53:23] <mru> how large is it? [11:53:23] <Dark_Shikari> It isn't finalized yet, it's a beta copy [11:53:24] <Dark_Shikari> but it's basically done [11:53:27] <Dark_Shikari> it's ~2GB [11:53:34] <Dark_Shikari> And yes it's DVD5 compliant [11:53:41] <Dark_Shikari> i.e. its maximum bitrate matches DVD transfer rates [11:53:44] <Dark_Shikari> so you can burn it to a cheap DVD-R [11:53:53] <mru> good [11:53:55] <Dark_Shikari> contains Elephant's Dream, Big Buck Bunny, and Tallship [11:54:03] <Dark_Shikari> Tallship being a camera HD source contributed by Microsoft [11:54:06] <Dark_Shikari> under an absurdly liberal license [11:54:08] <mru> I do have a bluray burner, but discs are pricey [11:54:18] <Dark_Shikari> we included that so that the disk didn't only include CGI content [11:54:26] <mru> url? [11:54:41] <Dark_Shikari> it's still only on an FTP that the guy requested me not to post because he doesn't have tons of bandwidth =p [11:54:48] <Dark_Shikari> when we release the official one there will be at the least a torrent [11:55:16] <av500> Dark_Shikari: but there is this one: http://www.blender3d.org/e-shop/product_info_n.php?products_id=106 [11:55:42] <av500> its BBB and ED [11:55:48] <Dark_Shikari> Yea, and it's not made with x264 [11:55:51] <av500> ah right [11:55:52] <Dark_Shikari> Probably some proprietary encoder [11:56:09] <Dark_Shikari> to michael: [11:56:10] <Dark_Shikari> 19:53 < Kapsel_> btw, seems like the ffmpeg build I found, is trying to use some kind of ascii colors for the output. is there any way to disable this? it doesnt quite work, at least not in my prompt. [11:56:12] <janneg> KotH: I've no idea what's the problem. There was another scene which took even longer 10-11 hours on my quadcore [11:56:17] <Dark_Shikari> (windows user) [11:56:30] <Dark_Shikari> mru: http://mirror05.x264.nl/Dark/bluray/ [11:56:42] <Dark_Shikari> Raw audio files (uncompressed or flac) and raw h264 can be found there [11:56:48] <Dark_Shikari> Not a proper blu-ray image obviously [11:57:03] <mru> I have plenty of h264 files [11:57:22] <mru> btw, ffmpeg refuses to transcode your ironman.mkv [11:57:32] <mru> something about invalid timestamps [11:57:39] <av500> it refuses to transcode any mkv here [11:57:42] <Dark_Shikari> gotta love ffmpeg's matroska demuxer disaster [11:57:54] <mru> piping it as rawvideo works of course [11:58:04] <av500> -vcodec copy [11:58:19] <av500> so, transmux [11:58:26] <Yuvi> demuxer's usually fine, it's the timestamp everywhere else that's screwed up [11:58:31] <mru> this one fails with -vcodec anything [11:58:34] <Yuvi> timestamp handling [11:58:45] <mru> it's because mkv stores only pts [11:58:48] <av500> Could not write header for output file #0 (incorrect codec parameters ?) [11:58:56] <mru> and lavf invents wrong dts for frames [11:59:07] <mru> no, it does ~500 frames correctly [11:59:11] <mru> then it fails [11:59:20] <mru> or starts duplicating frames [12:00:04] <av500> [mp4 @ 0x80913b0]track 1: codec frame size is not set [12:00:38] <av500> ah, once i set -an, it fails with the usuaal timestamp error [12:01:54] <Yuvi> mru: works for me (maybe off by one frame thanks to -vsync 1?) with -vcodec mpeg4 [12:02:07] <mru> I don't want -vsync 1 [12:02:09] <mru> it's wrong [12:02:13] <mru> it duplicates frames [12:02:16] <Yuvi> true [12:02:38] <mru> it shouldn't do that [12:02:56] <Yuvi> yeah, fails with -vsync 0 [12:03:42] <pengvado> <Dark_Shikari> there's huge incentive to optimize your decoder to make it appear to be lower complexity [12:03:46] <pengvado> there would be nothing wrong with that if they weren't comparing to JM [12:05:06] <Dark_Shikari> pengvado: exactly [12:05:18] <Dark_Shikari> my point in its entirety ;) [12:07:18] <av500> Dark_Shikari: why does ffplay refuse to play tallship.h264? [12:07:45] <av500> it plays a few frames then stops [12:07:53] <mru> I see that a lot with ffplay [12:08:00] <mru> probably something with timestamps [12:08:02] <Yuvi> frame dropping code probably [12:08:46] <Yuvi> at least, I didn't see that before it [12:09:07] <wbs> av500: try -noframedrop [12:09:34] <av500> thx [12:10:32] <av500> oops, ffplay seeks in .h264 files [12:11:48] <Yuvi> mru: I think the issue is that ffmpeg chooses a timebase of 1/24 since that's what's written in the codec, and two timestamps from the mkv are rounded to the same value [12:12:05] <Dark_Shikari> but that isn't what's written in the codec [12:12:12] <Dark_Shikari> tallship uses 60fps [12:12:18] <Yuvi> ironman [12:12:25] <Dark_Shikari> oh [12:12:29] <mru> every time someone complains about timestamps, michael prints another number in the info dump [12:12:46] <mru> ironman has like 5 different timebases reported [12:13:17] <Dark_Shikari> just use container and be done with it [12:13:38] <mru> if codec and container differ, how do you know which is correct? [12:13:49] <mru> with avi codec is correct more often than container [12:14:58] <Yuvi> container is probably more correct except if the codec has a (mangled) ntsc timebase [12:15:08] <mru> why? [12:16:23] <Yuvi> isn't the container what all the players use for timestamps? [12:17:31] <Yuvi> for avi in particular the only disagreement I've seen is with mangled ntsc [12:19:59] <mru> with avi I've seen every butchering possible [12:20:06] <mru> and a few impossible ones [13:16:05] <CIA-7> ffmpeg: michael * r22953 /trunk/libavutil/log.c: Trying _WIN32 for win32 detection. [13:41:35] <twnqx> so if apple would really buy arm [13:41:42] <twnqx> would that change any of the exiting licensing? [13:41:47] <twnqx> existing* [13:42:06] <mru> why would apple buy arm? [13:42:10] <mru> seriously [13:42:31] <Dark_Shikari> they have fucktons of money [13:42:33] <Dark_Shikari> like, holy shit [13:42:40] <Dark_Shikari> also, vertical integration [13:42:41] <mru> sure, but why should they spend it on arm? [13:42:48] <mru> it doesn't make sense [13:42:52] <Dark_Shikari> vertical integration [13:42:57] <RTFM_FTW> uh no [13:42:59] <RTFM_FTW> no no no [13:43:00] <mru> that phrase means nothing at all [13:44:05] <Dark_Shikari> apple is historically a very vertically integrated company [13:44:14] <Dark_Shikari> mru: http://en.wikipedia.org/wiki/Vertical_integration [13:44:15] <mru> the only reason they could have for buying it is to restrict access to other companies [13:44:25] <mru> but then the costs would shoot up [13:44:33] <Dark_Shikari> for example, Carnegie Steel was a historically vertically integrated company [13:44:35] <RTFM_FTW> they don't need ARM... they already have the necessary IP licenses and the ability to fab their ASICs where they see fit [13:44:35] <mru> they'd have to foot the entire r&d bill themselves [13:44:36] <twnqx> estimates say 6 billion [13:44:37] <Dark_Shikari> or Standard Oil [13:44:44] <twnqx> with apple having 30 in cash [13:44:50] <Dark_Shikari> and 13.5b in quarterly income [13:44:54] <Dark_Shikari> er, profit [13:45:00] <Dark_Shikari> *net income [13:45:34] <mru> besides, does apple have any interest at all in making microcontrollers for industrial applications? [13:45:35] <kierank> like brewery's owning pubs [13:45:44] <mru> that's where most of arm's revenue comes from [13:46:09] <av500> mru: that would be spun off immideately [13:46:31] <twnqx> on the other hand, if it's profitable.. [13:46:45] <mru> but it's arm7 and arm9 sales that fund the cortex development [13:46:46] <mru> in part [13:46:57] <av500> twnqx: customer would not buy from apple [13:47:01] <BBB> I doubt that the gov would allow them to merge [13:47:15] <BBB> wouldn't DoJ or some gov instance here immediately block it? [13:47:40] <av500> ministry of funny walks would [13:47:42] <kierank> eu maybe [13:47:58] <Dark_Shikari> BBB: but apple can't be a monopoly [13:47:59] <mru> I don't imagine nokia liking such a deal much [13:48:11] <mru> or sony-ericsson, or htc, or etc, etc [13:48:12] <BBB> Dark_Shikari: monopoly is not the reason mergers are blocked [13:48:16] <Dark_Shikari> everyone knows that everything apple does is correct ;) [13:48:30] <BBB> DoJ blocks mergers if they create unfair advantages or unfair competition [13:48:33] <BBB> that's != monopoly [13:48:35] <Dark_Shikari> I know [13:48:41] <Dark_Shikari> And yeah, a LOT of companies would object to that. [13:48:41] <mru> arm has a more or less monopoly on mobile processors [13:48:49] <BBB> arm being owned by one of its clients is VERY unfair to its direct competitors [13:49:00] <BBB> DoJ knows that [13:49:04] <mru> putting that in the hands of one phone manufacturer would be a very bad thing [13:49:08] <BBB> right [13:49:15] <mru> arm are that rare, well-behaved monopolist [13:49:17] <BBB> it's just a rumour anyway [13:49:47] <mru> the arm boss was quoted saying such a deal would be pointless [13:53:23] <Dark_Shikari> http://www.marketwatch.com/story/apple-passes-microsoft-on-sp-500-market-ca… [13:56:54] <BBB> Dark_Shikari: why you up so early? :) [13:57:01] <BBB> isn't it like 7am for you? [13:57:29] <Dark_Shikari> I woke up like 3 hours ago [13:57:48] * BBB falls asleep :-o [14:08:49] <scaphilo> anyone knows a little bit more about mpeg4part2 qscale and dquant? im not sure if i understand that correctly. [14:09:09] <Dark_Shikari> what about it [14:09:19] <mru> it's an ugly spec [14:09:48] <scaphilo> am i right that in macroblocks there are only differential values. Not like in mpeg2 where you store the absolut value of qscale? [14:10:05] <Dark_Shikari> er, I'm pretty sure mpeg-2 stores dquants too [14:10:20] <scaphilo> oh really? ups [14:11:38] <scaphilo> ill have to check that, but dquant of current macroblock is the difference between the last macroblock's qscale and the current one? [14:12:11] <Dark_Shikari> yes [14:14:17] <scaphilo> thx [14:14:19] <mru> is there an mpeg4 spec with all the crap cut out? [14:14:33] <scaphilo> you mean this 3d things ;-) [14:14:41] <mru> and the rest of it [14:15:30] <scaphilo> i dont know, i was looking for something like that as well [14:15:34] <Dark_Shikari> it's not that hard [14:15:38] <Dark_Shikari> you're doing mpeg2 transcoding [14:15:52] <Dark_Shikari> so the dquant restrictions don't apply [14:15:57] <Dark_Shikari> there's no dquant in 4mv blocks but you aren't using 4mv blocks [14:16:10] <Dark_Shikari> there's dquant restrictions in bframes but bframes don't have to be transcoded exactly as they aren't referenced [14:17:14] <scaphilo> ah yes mpeg2 to mpeg4part2 openloop. It works with option qscale 1 and without bframes :-) [14:19:05] <scaphilo> hey about this bframes would you just refer to one of the pframes? and leave the other one? [14:19:16] <Dark_Shikari> no, I'd just convert bframes into bframes [14:19:18] <Dark_Shikari> no problem there [14:21:08] <scaphilo> i currently never tested with bframes because ffmpeg doesnt seem to use bframes in mpeg2 encoder. when i dont set bf=whatever [14:21:27] <Dark_Shikari> then set bf=whatever ;) [14:21:52] <scaphilo> well im a bit afraid of it ;-) first i fix that thing with qscale [14:45:48] <kierank> are there any there any good debuggers on linux? I'm fed up of gdb constantly locking up [14:46:43] <kierank> s/any there/ [14:47:12] <scaphilo> me but im not a debugger specialist [14:47:19] <Dark_Shikari> valgrind? ;) [14:48:10] <kierank> valgrind doesn't like mmap loaded binaries [14:48:35] <wbs> kierank: file a feature request, then :-) [14:50:26] <Dark_Shikari> ida under a vm? [14:51:14] <mru> kierank: loading with mmap directly, not dlopen? [14:51:36] <kierank> it's using merzbt's binary loader code for atrac3 [14:51:58] <kierank> it's a windows binary dump [14:52:27] <mru> that might get tricky [14:52:53] <kierank> gdb works ok but it locks up after a while [14:52:56] <BBB> kierank: I did that under gdb, worked fine for me [14:53:08] <mru> convert it to elf and use dlopen [14:53:09] <BBB> are you using some pre-alpha gdb version? [14:53:46] <kierank> I tried 7.0 in ubuntu and 7.1 I built myself and they both locked up. I guess it might be something the loaded code does [14:54:06] <BBB> try objconv as mru suggested [14:54:40] <mru> or if that doesn't work, teach the loader to dump it out as elf [14:54:48] <mru> you could use libbfd :-) [14:55:06] <mru> but wear safety goggles, or you'll probably tear your eyes out [14:55:39] <BBB> I tihnk it's time I learn configure magic [14:55:51] <BBB> how do I make wmavoice "require" fft/rdft? [14:57:02] <mru> wmavoice_select="rdft" [14:57:10] <mru> or fft or whatever it needs [14:57:37] <BBB> wmavoice_decoder_select? [14:57:45] <mru> yes [14:57:48] <mru> of course, my bad [14:58:37] <mru> looks like it needs rdft and dct [14:58:49] <av500> BBB: objconv? [14:59:00] <mru> objcopy [14:59:09] <av500> ah, this one I know [14:59:25] <av500> I know it was obj_dumb_down [14:59:28] <BBB> mru: patch on ML [14:59:32] <BBB> thanks for the hint [15:00:23] <BBB> should I keep it alphabetically ordered? [15:00:45] <av500> mru: may I assume you want to work on flash again? :) [15:00:57] <mru> BBB: I'm not too fussed about that [15:01:17] <mru> av500: :-) [15:02:25] <BBB> http://www.agner.org/optimize/ objconv, av500 [15:02:32] <BBB> hm, that was disordered [15:03:19] <av500> BBB: I wish I had that a few ys back [15:04:20] <BBB> it worked pretty darn well when I tried it [15:04:49] <av500> I once had to convert M$ COFF to TI COFF [15:05:04] <av500> and I had a halfway patched objdump that spoke TI coff [15:05:09] <mru> coff formats share little more than the name [15:05:26] <av500> but, objcopy can only dumb down, not copy between equal formats [15:05:41] <av500> so it dropped all relocs.... [15:05:50] <mru> in theory it can copy [15:05:55] <av500> in theora [15:05:58] <mru> but something usually prevents it from working [15:06:06] <av500> but in practice, it drops reloc in the "in" stage [15:06:08] <mru> it's like remuxing with ffmpeg [15:06:15] <mru> relocs = timestamps [15:06:19] <av500> unless you use them to actually performs relocatiobn [15:06:29] <av500> at the "out" stage, they are gone [15:06:35] <av500> yup [15:06:43] <mru> elf to elf works fine [15:06:50] <av500> I have a nice objcopy rottin somewhere that can do that ... [15:06:59] <mru> reminds me of that elf demuxer we need to write... [15:07:04] <av500> yes [15:07:20] <av500> and can somebody tell probe to not detect alf as mp3? [15:07:23] <av500> elf [15:08:07] <av500> as in ffplay ffplay [15:09:47] <mru> btw, the archos5 has really good standby time [15:09:58] <av500> thx [15:10:02] <mru> it's been sitting on my desk for a couple of weeks without being charged [15:10:20] <mru> battery is still at 75% or so [15:10:25] <av500> so, you compliment me on a useless product :) [15:11:07] <kierank> av500: stop complaining. you need more fanboys [15:11:43] <av500> right [15:17:43] <mru> av500: but now it hung while shutting down to install an update [15:18:10] <av500> gee [15:18:33] <mru> and why does each update reinstall a fuckton of useless apps? [15:18:42] <av500> ask MKT [15:19:00] <av500> not in my hands [15:19:02] <mru> removing all those apps every time it updates is annoying [15:19:52] <mru> I can tolerate a few bundled apps with a new device [15:20:03] <av500> i know [15:20:06] <mru> but the update should check if they've been removed and not reinstall them [15:20:23] <av500> thats not so easy i was told [15:20:53] <mru> oh really [15:21:03] <mru> I'm sure building the device wasn't so easy either [15:21:05] <mru> but you did that [15:21:18] <av500> imagine what fun we had when mkt told us in last minute that the list of bundled app is "of course" per country specific [15:21:28] <av500> like 1week before launch [15:21:39] <mru> oh, so that's why it installs all those us-only apps? [15:21:59] <av500> mru: please dont ask me things like that [15:22:25] <av500> but, come on "high paying jobs" is the app for you, no? :) [15:22:31] <j-b> 'morning [15:22:38] <av500> 'jour [15:23:11] <BBB> hi j-b [15:28:11] <av500> ffmpeg in linuxtag could be mentioned on ffmpeg.org as news? [15:28:24] <BBB> when is linuxtag? [15:28:28] <av500> 9-12 6 [15:28:51] <av500> and ffmpeg.org has no rss feed? [15:30:10] <j-b> do you have a booth there? [15:30:28] <av500> yup [15:30:44] <av500> berlin = wall, you know [15:30:50] <BBB> wasn't there going to be a talk? [15:30:56] <BBB> I see no ffmpeg on the program anywhere [15:31:14] <mru> said who? [15:31:29] <av500> "why theora sucks" [15:32:45] <lu_zero> yawn [15:32:54] <lu_zero> when is linuxtag? [15:32:54] <av500> so, no talk [15:32:59] <av500> 9-12 6 [15:33:02] <kierank> Is it true that in germany you have beer with your lunch at work av500? [15:33:22] <lu_zero> kierank: is that strange? [15:33:24] <mru> do you have a problem with that? [15:33:29] <mru> beer is good [15:33:29] <kierank> no [15:33:34] <av500> kierank: depends [15:33:45] <av500> but mostly no [15:33:53] <av500> in bavaria, but then not the young ppl [15:34:09] <av500> but some do, yes [15:34:25] <av500> which reminds me of the crate of beer behind me [15:34:34] <lu_zero> uhmm [15:34:56] <lu_zero> how many people will come from the south? [15:35:52] <av500> lol http://twitter.com/joshdev/status/12706303667 [15:36:21] <kierank> reply from the ffmpeg account [15:36:29] <kierank> "we sure are" [15:36:38] <av500> who owns that [15:37:07] * kierank votes KotH [15:40:50] <janneg> there is talk from fluendo http://www.linuxtag.org/2010/en/program/free-conference/wednesday/details.h… [15:40:50] <av500> mru: they tell me you can say no to the wizzard [15:41:38] <mru> I'll have to look more carefully next time [15:41:47] <mru> at least this time it didn't try to do a factory reset [15:42:05] <mru> like the last 4 or 5 times it decided it was the first time running android 1.6 [15:42:08] <janneg> "FOSS applications for multimedia aren’t many and don’t offer the same quality and variety that could be found in other OS, such as Mac OSX or Windows" [15:42:30] <Dark_Shikari> lol [15:43:13] <av500> lol [15:43:28] <av500> mru: yeah, that one is a bug [15:43:36] <av500> that should be fixed with latest release [15:43:44] <mru> yeah, it didn't do it this time [15:44:00] <mru> it did insist on calibrating the touchscreen and accelerometer though [15:44:11] <av500> yes, that is more for noobs [15:47:16] <av500> mru: it has a proper browser now: http://www.openaos.org/tmp/2010-04-23-154245.jpg [15:48:01] <mru> how is that more proper? [15:50:37] <janneg> and FFmpeg is of course misspelled and they imply that it breaks laws [15:51:04] <Dark_Shikari> because they're fluendo [15:51:11] <av500> janneg: abmahnung! [15:51:53] <janneg> we could just troll the talk [15:52:04] <av500> ack [15:54:39] <av500> ffmpeg vs commercial codecs is totally orthogonal to the patent situation [15:55:40] <Dark_Shikari> av500: their products are worse, therefore they must rely on FUD [15:57:41] <BBB> someone should explain them that you can (according to LGPLv2.1) buy a patent license for ffmpeg, resell it for money as long as the patent license itself allows free software to be bundled with it [15:58:01] <Dark_Shikari> BBB: they _know_ this [15:58:04] <Dark_Shikari> they aren't stupid [15:58:10] <BBB> then why don't they resell ffmpeg? [15:58:13] <Dark_Shikari> they're just a company trying to peddle shitty products via FUD [15:58:16] <Dark_Shikari> because ffmpeg isn't their product! [15:58:17] <BBB> $$profit$$ [15:58:50] <BBB> so? [15:58:56] <BBB> you don't need to own a product to resell it [15:59:00] <BBB> as long as you have a license to resell [15:59:05] <BBB> = LGPLv2.1 [15:59:11] <BBB> \o/ [15:59:15] <BBB> $$profit$$ [15:59:32] <Dark_Shikari> And? [15:59:33] <Dark_Shikari> NIH. [15:59:36] <BBB> oh right [15:59:39] <BBB> yes, that's true [15:59:43] <av500> BBB: I doubt any of our codec licenses mandates anything about open vs closed src [15:59:50] <Dark_Shikari> I have the h264 one, it definitely doesn't [16:00:00] <BBB> av500: I know it doesn't, because most people with such licenses use ffmpeg [16:00:01] <BBB> :) [16:00:06] <BBB> just fluendo doesn't [16:00:15] <BBB> makes you wonder why... [16:00:45] <av500> BBB: because anybody can look up the patent licence price and substract it from fluendo price [16:01:14] <mru> and then look up ffmpeg price [16:01:26] <av500> mru: the emotional? [16:01:44] <mru> there's risk of flaming of course [16:02:19] <av500> btw, german supreme court upholds M$ FAT patents.. [16:02:37] <kierank> needs more currency symbols [16:02:40] <mru> how can fat patents still be valid? [16:02:55] <av500> 1994-10-05 [16:03:04] <mru> isn't fat from like 1982? [16:03:15] <av500> fat32 [16:03:16] <av500> LFN [16:03:37] <janneg> not only uphold but overturned a ruling from the bundespatentgericht saying that the patent is invalid [16:03:43] <av500> right [16:03:55] <mru> bent judges are nothing new [16:04:20] <kierank> I would mention a particular libel judge in london [16:04:37] <kierank> but that might be a bit ironic [16:04:43] <mru> like they said in the italian job, everyone in the world is bent [16:14:59] <BBB> that's why we need a foundation, so we can re-bribe them to the rigt side [16:15:05] * BBB runs [16:18:08] <av500> we can order a hit on them you mean [16:18:10] <av500> can [16:18:12] <av500> can't [16:21:08] <spaam> KotH: dont blame me for that [16:29:01] <CIA-7> ffmpeg: mru * r22954 /trunk/ (libavcodec/audioconvert.c configure libavutil/libm.h): Workaround for missing llrintf() [16:29:27] <mru> that should bring back the DOS build [16:30:49] <janneg> yeah! :) [16:31:07] <mru> and also a secret platform I'm working on [16:32:37] <av500> beer! [16:34:50] <BBB> mru: that looks wrong [16:34:53] <janneg> where is the multibyte char in alldevices IIC fails over? [16:35:12] <BBB> mru: it's intentionally 32-bit, if float-to-32bit overflows, it should truncate [16:35:26] <BBB> so this would ideally be implemented in a different way [16:36:00] <mru> I don't see how it's wrong [16:36:13] <mru> llrintf converts a float to long long [16:36:17] <BBB> llrintf(x) { x/=256.; y=rintf(x); return clipped_y << 8; } [16:36:19] <mru> so does the replacement [16:36:32] <BBB> it fails if it overflows [16:36:36] <BBB> which is the whole point of the function [16:36:37] <mru> no [16:36:43] <mru> if what overflows? [16:36:47] <mru> rint returns double [16:37:05] <mru> it's not going to overflow long long [16:37:11] <BBB> wait, I might say something stupid [16:37:14] <BBB> aha [16:37:16] <BBB> ok, sorry [16:37:19] <BBB> I misunderstood [16:37:27] <BBB> I thought you used the one returning long or int [16:37:37] <mru> that's lrint [16:37:41] <BBB> got it [16:37:41] <mru> there isn't on returning int [16:37:45] <mru> one [16:38:01] * BBB curses at the multitude of *rint*() functions [16:38:17] <mru> oh, I'm with you on that one [16:39:16] <mru> but thanks for checking anyway [16:42:49] <CIA-7> ffmpeg: rbultje * r22955 /trunk/configure: Make WMAVoice decoder depend on DCT/RDFT [16:44:25] <BBB> is that Makefile patch ok also? [16:45:10] <mru> I suppose [16:45:37] <mru> those common bits should really be given their own symbol [16:45:47] <mru> but we can do that later [16:45:53] <BBB> what do you mean? prefix? [16:45:55] <mru> adding the missing one doesn't break anything [16:46:05] <mru> no, a CONFIG_ symbol [16:46:10] <mru> like FFT [16:46:28] <CIA-7> ffmpeg: rbultje * r22956 /trunk/libavcodec/Makefile: Add acelp_filters.o as QCELP decoder object file. [16:46:35] <BBB> oh, aha [16:46:40] <BBB> yes, I guess [17:20:06] <hyc> hey cool, VP6 acceleration. mru, thought you didn't have any motivation to do that yet [17:20:27] <mru> maybe something motivated me [17:20:44] <kierank> lol [17:21:10] <mru> 10% more speed for an hour's work ain't bad [17:25:50] <BBB> maybe is another word for money? [17:27:05] <kierank> or beer [17:28:02] <jai> or girls [17:29:53] <mru> girls are the last thing I expect to motivate me on this [17:30:07] <mru> but yeah, they're pretty good motivators [17:30:18] <hyc> lol [17:30:38] * BBB looks for random stuff to do next [17:31:04] <mru> you could find aurelien and have him ack the patch [17:31:04] <jai> *cough* multichannel resampling *cough* [17:32:15] <kierank> *cough* find these elusive bugs I've beeing trying to locate in the dolby code [17:32:36] <BBB> well if you're already doing these two things, why would I do them? [17:32:47] <BBB> that totally defeats the purpose of you being my minions :-p [17:32:54] <jai> lol [17:33:21] <jai> BBB: maybe write some html for ffmtech.org [17:33:30] <jai> i assure you no one is doing that :) [17:33:33] <BBB> I guess... [17:33:36] <BBB> :) [17:33:59] <kierank> i'd update the lighttpd on that server [17:34:08] <mru> do whatever helps us dominate more [17:34:40] <mru> kierank: blame debian for the version [17:34:40] <kierank> it's quite old and there were definitely some vulnerabilities in it recently [17:34:50] <mru> it's got patches [17:35:01] <kierank> that's ok then [17:36:34] <jai> use nginx, later we can scale in the cloud too ;) [17:36:56] <kierank> ffmpeg as a service [17:36:58] <kierank> FaaS [19:08:14] <astrange> hmm gcc's loop optimizer likes to promote all iteration variables to intptr_t and waste some stack space [19:13:54] <mru> wouldn't be more efficient if we reported every time gcc did something right? [19:23:39] <Dark_Shikari> lol [19:26:18] <astrange> well it [19:26:24] <astrange> 's pretty reasonable on this file except for that [19:26:45] <astrange> oddly llvm is absolutely terrible. i'm too lazy to file regressions for that since they keep adding new ones [19:30:18] <kierank> I have something good to say about gnu. gdb reverse execution is actually quite useful [19:33:39] <nfl> merbanan, ping [19:39:55] <merbanan> pong [19:40:34] <nfl> hi, why would testing the g723.1 code be hard? [19:41:10] <nfl> thats what you said in my patch review [19:41:26] <merbanan> do we have any reference files to test with ? [19:41:31] <merbanan> and reference output ? [19:41:50] <merbanan> or did I say that about the rtp code ? [19:42:07] <nfl> couldn't we use the reference encoder for that? [19:42:14] <nfl> nope, not the rtp code [19:42:35] <merbanan> then it is easy to test [19:42:49] <nfl> ok [19:42:49] <merbanan> just use the refencoder [19:44:35] <nfl> if you have time, could you tell me if I've got CODEC_CAP_SUBFRAMES set up correctly in my patch? [20:17:20] <merbanan> nfl: do you have svn access ? [20:18:29] <nfl> merbanan, for checkout? [20:19:01] <merbanan> for checkin [20:19:07] <nfl> merbanan, nope [20:19:25] <merbanan> send an email to diego and request one for the soc repo [20:19:48] <merbanan> nfl: what date did you send the patch ? [20:19:58] <merbanan> the one you want me to look at [20:20:04] <nfl> merbanan, today i guess [20:20:16] <nfl> bit confused abt the timezones :) [20:20:32] <nfl> the latest one in the soc ml [20:20:50] <merbanan> there we go, it was badly sorted [20:21:12] <nfl> you should use gmail ;) [20:22:03] <merbanan> why did you use CODEC_CAP_SUBFRAMES ? [20:22:32] <nfl> to handle rtp packets that may contain multiple frames [20:22:49] <nfl> as suggested by BBB instead of a parser [20:23:13] <merbanan> why doesn't the demuxer split the packets correctly ? [20:23:31] <nfl> there is no demuxer [20:23:38] <BBB> (the demuxer doesn't always know how to do that) [20:23:53] <merbanan> BBB: the rtp thingy I guess ? [20:23:59] <BBB> yeah [20:24:02] <BBB> "thingy" :) [20:24:33] <merbanan> yeah ;) [20:24:58] <nfl> ah sorry, the rtp demuxer [20:28:47] <merbanan> nfl: the G723_1_Context and G723_1_Frame can be merged [20:29:23] <nfl> merbanan, ok [20:30:26] <merbanan> nfl: temp = get_bits(&gb, 13); <-- name temp better [20:31:33] <merbanan> nfl: when you get soc repo access, commit it, no need for more review, the code will be looked at more after you add more code [20:32:03] <merbanan> nfl: create some ref sample, implement a demuxer for that format so you can run the bitstream through the decoder [20:32:13] <merbanan> ref samples [20:32:49] <BBB> don't we have some on mphq? [20:32:59] <merbanan> nope [20:34:43] <merbanan> nfl: after that continue with synthesis [20:34:46] * BBB passed the 300-patch mark in ffmpeg o/ [20:34:53] <merbanan> nfl: any questions ? :) [20:35:21] <nfl> no sir :) [20:36:06] <merbanan> goodie, should keep you bizzy for a while, can you email me the spec you have also ? [20:36:32] <nfl> ok [20:44:58] <nfl> merbanan, have sent it [20:45:26] <nfl> btw the stuff you asked me to do will take me a while, i'm spat in the middle of exams. hope this is ok [20:46:35] <merbanan> sure, work on your exams [20:47:36] <merbanan> nfl: send your schedule for the summer also [20:47:58] <merbanan> after you did your exams that is [20:48:17] <nfl> ok [20:48:46] <nfl> btw are you from sweden? [20:49:04] <merbanan> YES! the kingdom of Sweden [20:49:27] <nfl> :) [20:49:29] <nfl> just wanted to brag to friends [20:49:37] <merbanan> hahaha, you do that [20:51:54] <merbanan> nfl: you resided somewhere in India ? [20:52:57] <merbanan> nfl: when you brag, you can say that I am from The GREAT kingdom of Sweden, famous for the pirate bay and blue eyed blonde girls [20:55:25] <nfl> crap [20:55:35] <nfl> merbanan, did you get the spec yet? [20:56:17] <merbanan> nope, but I got a mail that said that they where attached [20:56:53] <BBB> hehe :) [20:57:42] <nfl> hey don't blame me. its always my crappy connection [20:58:52] <merbanan> nfl: well I don't need them now, just send them sometime next week [20:59:38] <nfl> attempting again... [21:08:31] <nfl> merbanan, here: http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.723.1-200605-I!!SO… [21:10:06] <merbanan> jolly good [21:11:04] <merbanan> look at that, ref samples [21:11:24] <nfl> yup [21:13:19] <BBB> that server is slow... [21:13:39] <BBB> maybe place them on mphq... [21:15:18] <merbanan> nice, reordering tables [21:15:35] <merbanan> there is some work for someone to do :) [21:15:42] <kierank> BBB: itu server is always slow as hell [21:16:32] <nfl> bring it on :) [21:17:40] <merbanan> to bad the spec isn't self contained [21:18:26] <nfl> what do you mean? [21:19:56] <merbanan> you need to look at the ref code also [21:20:38] <merbanan> to write a decoder [21:20:48] <merbanan> can't only look at the pdf spc [21:22:44] <nfl> ok [21:28:33] <CIA-7> ffmpeg: michael * r22957 /trunk/libavutil/log.c: [21:28:34] <CIA-7> ffmpeg: 4th try at getting ansi colors working with a default of color=yes_please. [21:28:34] <CIA-7> ffmpeg: Colors will only be used if the TERM env var is set and NO_COLOR is not set. [21:32:52] <Dark_Shikari> lol [21:33:22] <BBB> poor Michael [21:34:56] <bcoudurier> hi guys [21:35:51] <janneg> bcoudurier: hi [21:37:26] <janneg> bcoudurier: do you know if there's a reason why the ts demuxer emits pes packets only after the next is started? [21:40:30] <bcoudurier> that's not always the case [21:40:51] <bcoudurier> it's because the pes packet length can be 0 [21:44:19] <janneg> yes, if the pes size is unbound it's obviously necessary [21:46:49] <janneg> bcoudurier: http://pastebin.com/Tqc5uj5M fixes delayed DVB subtitles in mythtv [21:47:35] <janneg> ffplay doesn't show the same problem since it queues audio, video and subtitle packets [21:47:54] <_av500_> and you dont? [21:48:00] <janneg> no [21:48:06] <_av500_> at all? [21:48:19] <_av500_> gee [21:48:21] <janneg> only video packets [21:48:51] <bcoudurier> indeed, gee [21:50:07] <_av500_> janneg: but the "next" pes packet is like a few bytes later, no? [21:50:43] <janneg> even if we did it's still a problem since there could minutes/hours until the next subtitle packet starts [21:50:56] <janneg> _av500_: the next pes packet on the same pid [21:51:23] <_av500_> and they are interleaved? [21:52:43] <bcoudurier> I think the patch is ok [21:52:49] <bcoudurier> I don't like the condition though [21:54:32] <janneg> total_size is the pes_data_length from the header, i.e. counting only the bytes after it [21:54:45] <janneg> that's there the 6 is comming from [21:56:08] <janneg> it should probably become a define [21:56:13] <bcoudurier> no define [21:56:25] <bcoudurier> I don't want to search through 3 files to find what vaue it is [21:56:40] <bcoudurier> commenting near the value is enough [21:56:43] <janneg> otherwise I don't see how I could make it prettier [21:56:58] <_av500_> color is used a lot these days [21:57:42] <janneg> GCC accepts rtf now or only ooxml? [21:58:41] <janneg> or html? and it ignore <blink>bla</blink> randomly? [21:59:30] <drv> maybe it has a javascript interpreter too, and we can then write cross-compilation-unit scripting exploits [22:13:39] <janneg> bcoudurier: patch sent [22:17:47] <bcoudurier> I'm not sure the 6 is right [22:19:26] <bcoudurier> humm no, it is [22:19:40] <bcoudurier> logic is obfuscated here [22:22:34] <bcoudurier> humm the size should be exact here [22:27:28] <janneg> yes, forgot to change it [22:32:49] <FUautotools> ffs, I wish log.c would stay static for a while [22:57:11] <bcoudurier> FUautotools, use releases [23:20:33] <Dark_Shikari> mru: do you think it's possible to get an h264 stream decoding in realtime on an iphone 3G? I.e. pre-Cortex. [23:20:46] <Dark_Shikari> i.e. with decent asm + encoder-side limitations [23:20:49] <RTFM_FTW> - yes [23:20:55] <Dark_Shikari> up to and including no deblock, no cabac, and no subpel [23:20:59] <Dark_Shikari> and by h264 stream I mean full iphone screen res

1 0

IRC log for 2010-04-22
by irc＠mansr.com 23 Apr '10

23 Apr '10

[01:30:46] <hyc> hmm. http://ingenient.com/resources/video_codecs/MP4145-DEC-Datasheet-2009.03.18… [01:31:07] <hyc> they only spec up to 352x480 for H.264MP decode on OMAP3 [01:31:29] <hyc> kind of an oddball resolution [01:32:37] <Compn> widescreen ? [01:32:51] <hyc> 352x480 is tallscreen :P [01:32:58] <Compn> oh yeah :P [01:33:32] <Compn> well horizontal is where its at, so they half ntsc dvd into that and anamorph it [01:34:41] <hyc> sounds about right [02:24:36] <ramiro> win64 builds are behaving oddly on av_find_stream_info(). it has code that uses double, and also calls decoders, which themselves use optimized code that use xmm registers and don't tell that to gcc. so after_try_decode_frame, the values that av_find_stream_info() had set up in some xmm registers are now bogus. [02:25:07] <ramiro> could someone please sum up why that is bad on win64 again and how to fix it? [02:28:12] <astrange> quick fix: write an asm wrapper around codec->decode() that saves and restores all the xmm registers [02:28:32] <astrange> un-quick fix: every dsputil function needs to mention the xmm registers it uses in the asm clobber list [02:34:29] <ramiro> astrange: for the quick fix, if any function inside codec->decode() uses doubles, it will screw up the same, right? [02:35:42] <astrange> hmm possibly yes [02:39:33] <Dark_Shikari> better fix: move everything to yasm [02:41:04] <ramiro> Dark_Shikari: hm, why would that be a better fix? [02:42:41] <Dark_Shikari> because yasm macros automatically handle win64 xmm clobbers [02:42:47] <Dark_Shikari> without having to compile with -msse2 [02:45:04] <ramiro> if I remove -msse2 will that stop gcc from using the xmm registers for doubles? [02:45:13] <ramiro> or use -mno-see2 or whatever [02:45:15] <astrange> -msse not sse2, surely [02:45:30] <astrange> if you disable it then it would ignore clobbers for it and not bother saving them, i guess [02:45:37] <astrange> but it makes no sense to disable sse on x86-64 [03:29:20] <Compn> how much would it cost to have mplayer.c reviewed and cleaned up by a professional ? can ffmpeg foundation pay for this ? :P [03:34:35] <Dark_Shikari> lol [03:34:52] <Dark_Shikari> since when are we not professionals? [03:35:01] <Compn> since when are you reviewing mplayer.c ? [03:35:19] <Dark_Shikari> lol [03:35:27] <Dark_Shikari> "we" includes you [03:35:30] <Dark_Shikari> why aren't you reviewing it? [03:35:32] <Compn> gasp [03:35:49] <Compn> i'm actually looking at it right now [03:36:33] <Compn> i'd like to use my super copy/paste skills, but i dont know what this static / extern char stuff is [03:37:27] <Dark_Shikari> what's hard about static [03:37:56] <Compn> probably nothing, i just havent read any programming books [03:38:23] <Dark_Shikari> neither have I, not since grade school [03:38:52] <Dark_Shikari> I don't understand, why would there be useful information about using C engraved on dead trees? [03:39:04] <Compn> gotta start somewhere [03:39:12] <Compn> guess i'll try wikipedia [03:42:01] <Compn> no one took the wikipedia troll? ;\ [03:42:03] * Compn sleeps [03:43:03] <Yuvi> hey, if you can learn how to program from reading wikipedia, I'll send you my hat [03:43:25] <Compn> is it a nice hat ? [03:43:43] <Yuvi> standard ballcap [03:43:50] <Dark_Shikari> bah, that sucks [03:43:53] <Dark_Shikari> I need a nice hat [05:17:49] <_av500_> _/\ [05:19:31] <elenril> ~^~ [05:36:52] <KotH> grüezi [05:51:59] <Dark_Shikari> how do I make gcc generate preprocessed source? [05:52:08] <astrange> -E [05:52:11] <Dark_Shikari> I have both gcc 4.4.3 and 4.6 segfaulting on the same code [05:52:14] <astrange> it's like in the manual and stuff [05:52:15] <Dark_Shikari> Which is pretty impressive [05:52:27] <Dark_Shikari> If I submit a bug, should I submit it on 4.6 or 4.4.3? [05:53:14] <astrange> 4.6 but stick both versions in the title [05:53:17] <Dark_Shikari> ok [05:58:13] <Dark_Shikari> their bug tracker doesn't seem to have a place in the submission form to put preproc'd source/ [05:58:55] <astrange> you can attach stuff in replies [05:59:25] <Dark_Shikari> ok [06:05:54] <DimStar> Good morning guys: anybody remembers the discussion we had yesterday about libswscale and the weird, empty function? It does not work with the #ifdef around the function block.See buildlog extract at http://www.pastebin.org/166998 [06:15:08] <DimStar> An updated patch, that changes the if (HAVE_7REGS) to #ifdef HAVE_7REGS can be found at: http://www.pastebin.org/167000 (fully untested... don't even know yet if it builds.. will let you know later) [06:16:35] <Yuvi> DimStar: why are you changing HAVE_7REGS from always being defined? [06:17:38] <DimStar> Yuvi: If it wuold always be defined I would not run into issues when building (like no-return-in-nonvoid function in _template.c... there was a lengthy discussion yesterday evening about this. [06:17:59] <DimStar> I'm not changing the value of HAVE_7REGS by myself at any place. [06:19:36] <DimStar> Yuvi: the two functions at the bottom of the patch: RENAME(yuva420_rgb32) for example... in some builds I see them 'empty', as the #ifdef is inside the {} block. [06:19:38] <Yuvi> oh, you're moving the checks around to avoid warnings? [06:19:48] <Yuvi> check #if HAVE_7REGS not #ifdef [06:20:17] <DimStar> Yuvi: on openSUSE, we have code checks that abort a build on that specific warning (in this case it's arguably a false positive, in most cases it is not) [06:20:43] <DimStar> Yuvi: yes, you're right about #if vs #ifdef... my bad. [06:22:24] <DimStar> http://www.pastebin.org/167005 would be the result then [06:28:58] <DimStar> I'll be back this evening... [07:28:54] <wbs> who's got access to upload.ffmpeg.org and can move samples to samples.mplayerhq.hu? [07:29:29] <KotH> o/ [07:29:31] <KotH> which ones? [07:34:14] <wbs> KotH: I uploaded some to /amrnb-dtx- [07:34:21] <av500> KotH: I uploaded an asf with chapters like a mo ago, would be nice to have it in samples [07:34:24] <wbs> nodata yesterday [07:34:54] <KotH> wbs: destination directory? [07:35:05] <wbs> A-codecs/amr [07:35:56] <KotH> av500: files? dest? [07:36:08] <wbs> KotH: chmod the directory, too ;P [07:36:12] <av500> something _with_shapters.asf... [07:36:27] <KotH> wbs: done :) [07:36:34] <KotH> wbs: ok like this? [07:36:40] <KotH> wbs: or shal i rename anything? [07:37:03] <wbs> I think this is ok, thanks! [07:37:15] <KotH> av500: dest? [07:37:32] <av500> asf_with_chapters.wmv [07:37:50] <av500> asf-wmv I guess [07:39:58] * KotH hates fucking "everything on the internet is for free" fags [07:40:23] <av500> it is not? [07:40:35] <KotH> recent exchange on webmaster@mphq [07:40:56] <ohsix> the cost of duplicating information is indeed low [07:40:58] <KotH> A: i cannot access samples.mphq anymore, can you help me? [07:41:03] <KotH> US: what's your ip [07:41:06] <KotH> A: <ip> [07:41:20] <KotH> US: we banned you because of rules violation [07:41:26] <KotH> A: please restore my access [07:41:53] <ohsix> do you have a torrent for that stuff? [07:42:06] <KotH> no word of appology, nothing [07:42:25] <KotH> ohsix: for >40G of files that only a few are interesting to most people? [07:42:27] <av500> he said "please" [07:42:47] <av500> ohsix: i dount that torrent would live long [07:42:51] <ohsix> heh, maybe he didn't know or connect up what he did to a violation [07:43:01] <KotH> ohsix: go to samples.mphq [07:43:05] <KotH> ohsix: what do you see there? [07:43:22] <ohsix> torrents are always good [07:43:37] <KotH> ohsix: feel free to create a torrent [07:43:57] <KotH> ohsix: i'd give you also the permission to download all samples with max speed for this [07:43:59] <ohsix> i'd have to get the files to create the metadata [07:45:45] <av500> KotH: how about BOLD and RED for the relevent sentence? [07:46:29] <ohsix> or ratelimit it at the source; contact for fast access [07:48:37] <KotH> ohsix: you mean rate limit all access to samples to a total sum of 10kB/s ? [07:48:55] <KotH> 'cause everything else would not work [07:49:57] <ohsix> 50kbs, like on the info blurb; if people wanted to use multiple connections and get around it then they're jerks (though nginx or whatever could restrict that too) [07:49:59] <KotH> av500: wer lesen kann ist klar im vorteil... und wer nicht, wird halt geblockt [07:50:19] <av500> KotH: oder so :) [07:50:21] <KotH> ohsix: limiting to 50kB/s per person would not help [07:50:37] <KotH> ohsix: we have half china and russia wanting to download the samples [07:51:00] <KotH> ohsix: that'd be a few hundert to a few thousand concurent downloads [07:51:10] <KotH> -> way too much traffic [07:52:17] * av500 wonders what they want them for [07:52:22] <ohsix> heh, are the people who would mirror willing to join the torrent? [07:52:46] <KotH> av500: i have no clue [07:52:47] <ohsix> or order dvds for samples [07:53:10] <KotH> av500: especially considering that more than half of the files are so obscure i even dont know what they are good for [07:53:17] <av500> right [07:53:41] <av500> thx for the move [07:53:48] <KotH> ohsix: we cannot sell dvds.. if we do we would be liable for copyright violation and would have to pay compensation [07:54:17] <av500> sell DVDs with crypted data, leak the key :) [07:54:40] <KotH> ohsix: for most of the files, we do not have the right to distribute them. as long as we do not get any money from it, we're somewhat safe [07:54:41] <ohsix> then dont; do what the mame people do and offer for the price of media, shipping and "good will" [07:54:56] <KotH> ohsix: that's already enough [07:55:18] <ohsix> its also not you; its the people who are willing to do it but ar eotherwise unaffiliated [07:55:24] <KotH> ohsix: as soon as you touch money, you're a for-profit-entity [07:55:36] <av500> ohsix: I would not try to test that [07:56:20] <KotH> ohsix: the only legaly possible solution is to distribute over the inet for free [07:56:29] <ohsix> thats an interesting thing to say considering how people feel about patents in here :> [07:56:38] <KotH> well.. it's still not legal, but at least you are not liable for compensation [07:56:48] <KotH> patents != copyright [07:57:04] <KotH> these are two completely different things [07:57:10] <KotH> (although mixed way too often) [08:02:41] <ohsix> i was only speaking to the effort to get and stay into a grey area and defend it; unaffiliated people could start sending dvds and you wouldn't be liable [08:04:15] <ohsix> you wouldn't have a problem demonstrating the intent of the archive [08:06:55] <ohsix> and moreover you cant be held to the intent of any party that would do otherwise [08:42:13] <lu_zero> mru: you around? [08:42:47] <wbs> bcoudurier: thanks for the review, will address the comments soon :-) [08:42:57] <lu_zero> good morning [08:43:02] * lu_zero yawn [08:43:02] <lu_zero> s [08:43:33] <av500> t [08:43:49] <lu_zero> hi av500 =P [08:45:41] <wbs> bcoudurier: even if you wanted the muxer-related changes merged, I guess it's ok to keep the generic stuff from Yuvi's qt chapters as a separate patch, since I guess that will be applied quite soon anyway [08:48:35] <Dark_Shikari> mru: awesome! the official t-shirt of ffmpeg-devel [08:48:36] <Dark_Shikari> http://www.despair.com/timeforaction.html [08:54:53] <av500> Dark_Shikari: we could never agree on the color of such a shirt! [08:55:26] <lu_zero> av500: black and white is fine if you can't pick a color, don't =P [08:56:19] <CIA-7> ffmpeg: cehoyos * r22940 /trunk/ (ffplay.c ffmpeg.c): [08:56:19] <CIA-7> ffmpeg: Fix compilation error of ffmpeg and ffplay with --disable-avdevice. [08:56:19] <CIA-7> ffmpeg: Patch by Cyril Russo, stage D nexvision A laposte net [08:58:21] <CIA-7> ffmpeg: cehoyos * r22941 /trunk/libavformat/riff.c: [08:58:21] <CIA-7> ffmpeg: Support VP6F in Matroska. [08:58:21] <CIA-7> ffmpeg: Patch by Christian Schmidt, schmidt digadd de [09:05:28] <CIA-7> ffmpeg: thardin * r22942 /trunk/libavformat/flic.c: Made FLIC demuxer capable of handling the videos from "X-COM: Terror from the Deep". [09:07:07] <Tjoppen> there, finally. [09:11:19] <bilboed-pi> erf, vp6f riff code is ... FLV4 ? wtf :) [09:11:32] <Dark_Shikari> why not [09:11:43] <bilboed-pi> why not .. you know... VP6F ? :) [09:11:51] <Yuvi> I think mplayer is to blame [09:11:52] <Dark_Shikari> ask adobe [09:12:07] <bilboed-pi> Dark_Shikari, ... is that *seriously* an official mapping ? :) [09:12:11] <av500> adove puts VP6 in mkv? [09:12:13] <Yuvi> and vp6f came after such files exist flash stores it upside down [09:12:17] <Yuvi> exist since [09:12:25] <bilboed-pi> I'd be more with Yuvi on this one [09:13:13] <Yuvi> actually, maybe not [09:13:21] <Yuvi> don't see it in codecs.conf [09:15:52] <Yuvi> heh, wikipedia edit: 'There is no "h.264", only H.264' [09:18:29] <Yuvi> now I think g-spot is to blame [09:18:55] <av500> you found it? [09:20:09] <Yuvi> either that or http://forum.doom9.org/showthread.php?t=113655 [09:20:48] <KotH> ohsix: you are free to do so [09:20:52] <KotH> ohsix: i wont hold you back [09:21:03] <KotH> ohsix: just let me know which ip you are comming from before you start a download :) [09:24:02] <av500> KotH: please open 192.168.1.22 :) [09:27:20] <KotH> it's open :) [09:41:44] <CIA-7> ffmpeg: michael * r22943 /trunk/ffmpeg.c: [09:41:44] <CIA-7> ffmpeg: Make sure ffmpeg chooses a supported samplerte if the encoder supports [09:41:44] <CIA-7> ffmpeg: just some. [09:42:33] <CIA-7> ffmpeg: michael * r22944 /trunk/libavcodec/ (libmp3lame.c mpegaudioenc.c): Set .supported_samplerates for mpeg audio encoders. [09:48:11] <Tjoppen> ah, looks like michael noticed my suggestions yesterday [09:49:28] <av500> next thing could be to add an avlog WARNING if the reqd rate does not match exatcly [09:50:45] <Tjoppen> yep [09:53:09] <KotH> --- [09:53:11] <KotH> >> May I please request you to restore access to this collection. [09:53:11] <KotH> > Yes, you may request it. [09:53:12] <KotH> We would like to have access this collection. We hereby request you to unblock our IP and thereby enable us access the collection. [09:53:15] <KotH> --- [09:53:19] <KotH> .o0(stupidity prevails) [09:54:25] <av500> hereby and thereby! [09:55:31] <KotH> av500: $INDIAN_WORKING_FOR_BIG_OSCILLOSCOPE_MANUFACTURER [09:58:04] <av500> gee, they play video on the scope [09:58:23] * av500 looks at his nonvideo scope [09:59:10] <bcoudurier> anyone familiar with dts here ? [09:59:20] <av500> a tiny wee bit [10:02:35] <bcoudurier> do you think you can set the frame size in the parser ? :) [11:34:56] <BastyCDGS> hi 2 all [11:44:13] <pJok> mornings BastyCDGS [11:44:55] <mru> moroning [11:44:55] <BastyCDGS> greetz pJok...i'm in office...a bit later here than yesterday [11:45:02] <BastyCDGS> had to install git here too [11:45:12] <BastyCDGS> and to transfer the ffmpeg stuff from home to here [11:45:19] <BastyCDGS> but I'm ready to continue here as at home [11:45:38] <BastyCDGS> mohoin mru & av500 [11:47:12] <BastyCDGS> yasm is installed here now too [11:47:18] <BastyCDGS> test build was successful too [11:47:28] <BastyCDGS> so it just can go on ;) [11:51:23] <BastyCDGS> what's going on with you? [12:04:28] <BastyCDGS> anything interesting ;) [12:04:42] <BastyCDGS> ? [12:04:57] <BastyCDGS> about that fg/bg colored messaging [12:05:09] <BastyCDGS> it was stated that there's no way of determing the bg color [12:05:14] <BastyCDGS> (high contrast algorithm) [12:05:20] <BastyCDGS> so what we can do then? [12:05:24] <mru> nothing [12:05:51] <BastyCDGS> what's the problem with configure? if the params aren't passed the defaults are used [12:06:29] <av500> it makes no sense [12:06:32] <mru> it's useless bloat [12:06:42] <av500> what mru said [12:07:10] <BastyCDGS> so either use fixed fg/bg or drop the patch at all? [12:07:17] <av500> just red [12:07:20] <mru> I'd say drop the whole idea [12:07:22] <BastyCDGS> or just use bold/italic [12:07:26] <mru> it's impossible to do it cleanly [12:07:29] <BastyCDGS> bold + blink = fatal [12:07:32] <BastyCDGS> bold = err [12:07:34] <BastyCDGS> italic = warn [12:07:44] <mru> do not _ever_, under any circumstance, use blink [12:07:49] <av500> what mru said [12:08:03] <BastyCDGS> bold + italic = fatal? ;) [12:08:07] <BastyCDGS> or bold + underline? [12:08:19] <mru> most terminals can't do italic [12:08:37] <BastyCDGS> underline isn't supported always, too? [12:08:38] <hyc> I would swear that mru's last email came in bright red and blinking in my inbox :P [12:09:15] <hyc> (responding to the configure options for color settings ... ;) [12:09:19] <mru> if that's how you choose to configure your mail reader... [12:09:43] <BastyCDGS> ;) [12:10:08] <BastyCDGS> maybe then just bold for fatal + err [12:10:16] <BastyCDGS> warn nothing [12:10:32] <mru> people use the word fatal too lightly [12:10:35] <mru> fatal means YOU DIE [12:10:46] <hyc> I don't think warnings need any highlight [12:10:58] <hyc> you can use bold or inverse [12:11:02] <BastyCDGS> warn nothing sounds best to me then too... [12:11:03] <hyc> for error [12:11:31] <mru> this is all pointless [12:11:43] <mru> people with a clue will read the error messages as they are [12:11:52] <mru> people without one will ignore them even in red [12:11:54] <BastyCDGS> I already stated yesterday I want it be off (default) anyways ;) [12:11:56] <av500> mru: I would like errors in red [12:12:08] <av500> but then I also like colorgcc [12:12:13] <BastyCDGS> what about popping up 500 dialog boxes like in win on error :D [12:12:14] <BastyCDGS> *gg* [12:13:26] <mru> sure, I like colorgcc too [12:13:29] <hyc> inverse, bold, bold+inverse [12:13:54] <av500> red, bold [12:13:55] <hyc> that's the pool of options I would consider most reliable [12:14:08] <av500> red works on many backgrounds [12:14:13] <av500> bold works on all [12:14:29] <BastyCDGS> unless someone uses bold as default in a terminal hehe [12:14:33] <mru> these idiots wouldn't see the error message if it were written in their own blood [12:14:34] <BastyCDGS> but who does this [12:14:34] <av500> his problem [12:14:44] <av500> we are talkling std users [12:14:55] <av500> the ones that mis error msgs [12:14:58] <mru> my shell prompt is bold [12:15:03] <mru> yellow [12:15:04] <hyc> mine too [12:15:12] <av500> you are all so bold! [12:15:12] <mru> red if the last command exited with an error [12:15:16] * BastyCDGS thinks how to build a device which writes the error message into their flesh...shall I post a patch? :D [12:15:34] <hyc> I was just joking yesterday about "my background color is red" but still the point remains, using a fixed color is a bad idea [12:15:41] <mru> turn up the power on the dvd drive's laser... [12:16:02] <hyc> need an aiming mechanism :P [12:16:04] <BastyCDGS> mru, neat idea...like I did a floppy music on m68k asm [12:16:29] <hyc> mmm, we did floppy drive music back in the Apple II days [12:16:30] <av500> can we have shades of red for lavc vs lavf vs lavu errors? [12:16:44] <BastyCDGS> btw, does that work with CD/DVD drives, too? bring the laser to make music? [12:16:55] <hyc> as Henry Ford said, any color you like, as long as it's black [12:17:06] <mru> oh, and what about people reconfiguring the colours in their terminal? [12:17:17] <mru> most terminals let you choose which actual colours to use [12:17:20] <hyc> exactly [12:17:27] <hyc> so again, bold and inverse are reliable [12:17:33] <hyc> specific colors, not. [12:17:52] <mru> inverse is ugly [12:17:59] <hyc> errors are ugly [12:18:02] <mru> people look away from ugly things [12:18:05] <BastyCDGS> lol [12:18:25] <hyc> if you want beautiful output, don't have errors :P [12:19:38] <hyc> Why not just skip all this and put an extra blank line around error messages... [12:19:45] <mru> the real problem is that the ffmpeg output is far too verbose by default [12:19:53] <mru> error messages are masked by useless chatter [12:21:39] <BastyCDGS> hyc: not a bad idea either, maybe also add some indentation? [12:22:08] <FUautotools> People still won't see it [12:22:10] <BastyCDGS> hey what about doing a sinus scroller for errors? *gg* [12:22:11] <ohsix> and some ^V^G's [12:22:29] <BastyCDGS> like in the good old intros ;) [12:23:06] <hyc> too bad we can't use VT100 double-size character mode [12:23:11] <mru> ugh [12:23:12] <av500> btw, do we do this: http://utcc.utoronto.ca/~cks/space/blog/programming/HowToWriteToStderr [12:23:32] <ohsix> does ffmpeg still use ncurses? sure you could [12:23:51] <av500> ncurses for subtitles? [12:23:52] <mru> oh, that's just someone who just discovered line buffering vs block buffering and thinks he's smart [12:24:05] <mru> I'd rather not add an ncurses dependency [12:24:32] <FUautotools> Perhaps I should drop the not-windows parts since you people can't agree on a standard terminal [12:26:46] <BastyCDGS> hey [12:26:48] <BastyCDGS> I have an idea [12:26:56] <av500> cant we just start with error=red [12:26:58] <BastyCDGS> what about defining the color via an environment variable [12:27:02] <av500> and see how that works out [12:27:09] <av500> BastyCDGS: it is foor n00bs [12:27:12] <av500> not for us [12:27:15] <BastyCDGS> if env = N/A = red [12:27:18] <av500> ok [12:27:23] <av500> and drop the env :) [12:27:44] <FUautotools> Actually, I've got a better idea than colours... [12:27:56] <BastyCDGS> FUautotools, then tell... [12:28:02] <elenril> sounds? [12:28:07] <FUautotools> prefix the messages with "Error: ", "Warning: ", etc [12:28:18] <BastyCDGS> ERROR: [12:28:27] <BastyCDGS> uppercase would be better... [12:28:30] <av500> E_R_R_O_R_: [12:28:38] <FUautotools> with \a\a\a [12:29:10] <av500> $ banner error > stdout [12:29:35] <hyc> gothic error [12:29:42] <BastyCDGS> FUautotools: http://vanhu.free.fr/blog/public/guru-meditation.gif [12:29:46] <BastyCDGS> what about this? ;) [12:30:08] <FUautotools> Won't work on windows AFAICT [12:30:14] <hyc> if audio output is still working, play some annoying alarm bell [12:30:23] <BastyCDGS> was kidding ;) [12:30:29] <BastyCDGS> \b [12:30:34] <BastyCDGS> was bell [12:30:41] <BastyCDGS> if i'm not wrong... [12:30:45] <hyc> no, a wav file... [12:31:15] <BastyCDGS> what \b does is OS dependent, on linux KDE/windows you can configure the OS either use pc speaker or a custom WAV [12:31:40] <hyc> I wonder how many people use a VT52 or non-ansi terminal these days [12:31:59] <KotH> in the us? quite a few [12:32:04] <BastyCDGS> apart from this I'd be very careful about sound output [12:32:14] <BastyCDGS> it's annoying when you're listening to music etc. [12:32:20] <KotH> in the rest of the world: probably only very old legacy systems that nobody bothered to replace [12:32:26] * BastyCDGS hates websites which output sound without asking [12:32:53] <BastyCDGS> exception of course are sites like youtube where you expect that [12:33:09] <FUautotools> Huh? \b is a backspace \a is a bell [12:33:10] <hyc> anyway... XBMC's logger prefixes all messages with the level [12:33:22] <hyc> librtmp does that too [12:33:22] <elenril> even sites like youtube shouldn't start playback automatically [12:33:41] <av500> elenril: and lose half the audience? [12:33:49] * elenril doesn't care =p [12:34:19] <av500> hyc: I could like a 8 space prefix that is blank unless error: [12:34:24] <av500> [ ] doing foo [12:34:30] <av500> [ ERROR ] foo is on fire [12:34:38] <hyc> yeah, that would work [12:35:09] <av500> so it works even after |less etc [12:35:09] <BastyCDGS> [ FATAL ] foo is slain [12:35:16] <av500> or in log file [12:35:19] <hyc> exactly [12:35:28] <hyc> ANSI codes are .. messy ... [12:35:33] <BastyCDGS> sounds great for me too... [12:35:34] <ohsix> just dd' some urandom to the console [12:36:02] <av500> ohsix: that what ffmpeg does by default, no? :) [12:36:33] <hyc> oops. my /dev/urandom is a symlink to a file with 32768 0xff's [12:36:47] <BastyCDGS> lol [12:36:55] <mru> nine, nine, nine [12:37:16] <BastyCDGS> hyc, then take /dev/random ;) [12:38:36] <hyc> (it's a cheap trick, but effective when trying to break secure handshakes of unknown protocols...) [12:38:50] <BastyCDGS> mru, just reading your ml comment unix default is nothing...that's right and we should follow that [12:38:57] <hyc> it's also a bad thing to leave in place when you open an ssl session to your bank [12:39:46] * BastyCDGS encrypts only with twice rot13 :D [12:40:52] <BastyCDGS> best encryption algorithm is drink much alcohol, nobody can decrypt your spoken stuff anymore *gg* [12:41:34] <av500> BastyCDGS: triple rot13 is more scure! [12:41:48] <av500> like triple DES [12:41:58] <hyc> av500: now you're just being paranoid [12:42:49] <FUautotools> How about prefixes then: http://pastebin.org/167539 [12:43:06] <av500> yes, but not aligned [12:43:21] <av500> i mean, can they be aligned [12:43:43] <BastyCDGS> put the if else if stuff after the if loglevel return stuff [12:44:12] <hyc> and leave a blank prefix by default "[ ]" [12:44:19] <av500> yep [12:44:32] <BastyCDGS> does anyone uses non-fixed width term fonts? [12:44:42] <av500> yes, but we do not care for him [12:44:46] <hyc> that would be their problem [12:44:50] <BastyCDGS> we actually can't even [12:44:51] <mru> they can go f*ck themselves [12:44:58] <av500> they already do [12:44:58] <mru> in fact, they've already done so [12:45:02] <hyc> yep [12:45:32] <av500> ok, so thats settled, not what color do we make the prefixes? :) [12:45:36] <av500> now [12:45:44] <hyc> mauve [12:45:58] <mru> pale goldenrod yellow [12:46:00] <av500> teal [12:46:09] <BastyCDGS> I thought we left out the color stuff? [12:46:22] <hyc> yeah [12:46:28] <BastyCDGS> und just want [ $MSG ] [12:46:45] <BastyCDGS> maybe [b][ FATAL ][/b] blablah [12:46:51] <BastyCDGS> etc. [12:46:56] <BastyCDGS> so that the [ ... ] is bold [12:46:58] <mru> medium sea green [12:47:03] <FUautotools> Even bold is bard to do [12:47:03] <av500> off white [12:47:05] <BastyCDGS> #336699 [12:47:06] <FUautotools> *hard [12:47:13] <mru> blanched almond [12:47:17] <hyc> as for the prefixes, I would just have an array of strings, indexed by [level>>3] [12:47:18] <mru> rgb.txt is a hoot [12:47:38] <hyc> too many if statements... [12:47:53] <BastyCDGS> => switch case then [12:48:02] <hyc> btw, try red text on blue background, for a nice 3-D effect [12:48:08] <BastyCDGS> a table isn't bad too though [12:48:22] <mru> hyc: mere thought makes my eyes hurt [12:48:23] <FUautotools> Aligned with empty prefix: http://pastebin.org/167555 [12:48:40] <hyc> :P [12:48:43] <mru> hyc: you know why that happens? [12:48:50] <BastyCDGS> instead of if else if either table or switch/case [12:48:53] <hyc> yep, cone alignment in your eyes [12:49:03] <hyc> that's why red/blue 3-D glasses work [12:49:07] <mru> no [12:49:13] <FUautotools> A table will be big because FATAL != ERROR+1 [12:49:23] <BastyCDGS> so switch/case [12:49:32] <mru> FUautotools: >>3 [12:49:37] <av500> FUautotools: now u could optimize away 2 spaces per line [12:49:42] <BastyCDGS> but do it AFTER the if ( level > av_log_level ) return; [12:50:04] <BastyCDGS> it doesn't make sense to go through a bunch if switches/if stats if you return anyway without output sth. [12:50:06] <mru> hyc: red/blue glasses show a different image to the right/left eye [12:50:08] <ohsix> hyc: on a crt right? electron beamz go through the shadow mask at different angles [12:50:19] <mru> ohsix: that has nothing to do with it [12:50:21] <mru> works on lcd too [12:50:34] <hyc> mru: yes, but that's beside the point [12:50:40] <mru> the lens in the eye has a different refractive index for red and blue light [12:50:50] <mru> like just about any transparent thing [12:51:00] <av500> unless it is APO corrected :) [12:51:03] <mru> so red stuff gets focused at a different distance than blue stuff [12:51:13] <hyc> ah yes, right. [12:51:32] <hyc> it's physically impossible for the eye to be focused on both blue and red simultaneously [12:51:34] <ohsix> hur; focus, that wasn't what i was talking about anyways [12:51:44] <mru> equivalently, the lens needs to be set differently for red and blue stuff at the same distance be to focused on the retina [12:51:57] <BastyCDGS> btw, switch/case also creates a table automatically if there's a lot of them [12:52:06] <BastyCDGS> at least StormC did this on amiga [12:52:08] <mru> so the red and blue are perceived as being at different distances [12:52:15] <hyc> yep [12:52:48] <hyc> BastyCDGS: most compilers turn switch/case into a jump table [12:53:03] <hyc> but if you just use the right data structure you don't need a jump at all [12:53:45] <BastyCDGS> don't do they this only if the stuff done in case differs... [12:54:18] <BastyCDGS> i mean if you always have a single char * assignment there they could be smart enough to act on this [12:54:41] <BastyCDGS> I remember once being surprised what stormc outputted when doing sth. tucomposer stuff [12:54:57] <BastyCDGS> (standard out is normal jmp table, though) [12:55:11] <av500> BastyCDGS: I doubt ffmpeg spends much time in outputting log messages, and if it does, we have much larger problems... [12:55:35] <BastyCDGS> I think in this case it inlines internally the jump table function [12:55:36] <hyc> IMO, relying on the compiler to be too smart is just a bad policy [12:55:40] <CIA-7> ffmpeg: jai_menon * r22945 /trunk/libavformat/id3v2.c: Fix off-by-1 error in the tag parsing code. [12:56:07] <hyc> write better source code, get better object code [12:56:12] <BastyCDGS> btw, one question regarding patches [12:56:32] <BastyCDGS> file structure [12:56:38] <BastyCDGS> should I use: [12:56:47] * mru recalls doubling speed of aac decoder without writing a single line of asm [12:56:48] <BastyCDGS> ffmpeg-svn/foo/bar.c [12:56:51] <BastyCDGS> trunk/foo/bar.c [12:56:53] <BastyCDGS> ffmpeg/foo/bar.c [12:57:03] <BastyCDGS> what's preferred here and takes the least work for you all? [12:57:04] <BastyCDGS> just [12:57:04] <mru> whatever git diff does [12:57:06] <BastyCDGS> foo/bar.c? [12:57:22] <BastyCDGS> ok [12:57:43] <mru> something that works with patch -p0 or -p1 in the ffmpeg root [12:57:45] <hyc> git? I've been using svn [12:57:50] <hyc> is git the master now? [12:57:58] <BastyCDGS> with svn diff the output differed depending on the dir I was calling the svn diff cmd [12:58:05] <merbzt1> hyc: no [12:58:22] <mru> nevermind the backend repo [12:58:30] <mru> using git as frontend is still better [12:58:37] <hyc> ah [12:58:38] <merbzt1> indeed [12:58:51] <BastyCDGS> ah so I don't have to take care about the directory from where I call git diff? [12:59:03] <hyc> git always does the full path from repo base [12:59:10] <BastyCDGS> great [12:59:16] <BastyCDGS> then that issue is solved ;) [12:59:34] <FUautotools> switch: http://pastebin.org/167578 [12:59:53] <jai> BastyCDGS: diff from the root dir [13:00:03] <BastyCDGS> kk [13:00:06] <hyc> FUautotools: ugh, declaration after code [13:00:14] <hyc> I hate that aspect of C99 [13:00:15] <BastyCDGS> this would be foo/bar.c then in my example ;) [13:00:16] <FUautotools> ffmpeg is c99 [13:00:36] <hyc> it takes me all the way back to BASIC [13:00:41] <FUautotools> I can move that 2 lines up if nessecary [13:00:51] <BastyCDGS> the empty char * doesn't harm at the beginning regarding of perfomance [13:01:09] <hyc> right, there's no reason not to move the decl up [13:01:37] <hyc> and as av500 said, drop two spaces from each prefix [13:01:49] <hyc> WARNING will have no spaces, but no biggie [13:01:51] <FUautotools> [TEXT] then? [13:01:59] <av500> yes [13:02:10] <hyc> [ FATAL ] [WaRNING] [13:02:11] <BastyCDGS> which log level is [TEXT] then? SCNR [13:02:24] <ohsix> shell to figlet [13:02:40] <ohsix> or banner [13:02:52] * KotH paints the bikeshed blue [13:02:59] <av500> KotH: teal! [13:03:05] <hyc> banner is a bit extravagant, but I still like gothic [13:03:20] <ohsix> make it go to a printer like it's supposed to, too [13:03:36] <FUautotools> Somebody fix the shed so I don't have to paint it. [13:03:46] <KotH> av500: too late, it's already painted [13:03:57] <av500> [ERROR] is about fixing the user [13:04:21] <FUautotools> True, but people say ffmpeg is too verbose [13:04:29] <ohsix> play a melody on tty0 [13:04:38] <av500> well, now they have a nice way to regex it away [13:04:42] <hyc> http://pastebin.org/167587 [13:05:23] <av500> grep -v "[ ]" [13:05:34] <mru> 2>/dev/null [13:05:40] * mru does that a lot [13:05:51] <mru> and | md5sum [13:06:03] <av500> mru must have a huge /dev/null [13:06:11] <mru> watching it in code and all that [13:06:12] <hyc> hmmm, what do you need sum of stdout for? [13:06:21] <mru> -f rawvideo - [13:06:23] <av500> regression [13:06:27] <hyc> ah [13:06:53] <av500> or mru can see the matrix in md5 sums [13:07:00] <hyc> cool [13:08:36] <FUautotools> no c99, fewer spaces: http://pastebin.org/167598 [13:09:38] <av500> FUautotools: since the log masg start with [ anyway, we could drop the [] anyway, no? [13:10:16] <av500> bikeshed, I know [13:10:20] <mru> or combine it all [13:10:24] <FUautotools> If you want it in with the [codec @ hex] thing... [13:10:34] <av500> ack [13:10:51] <DonDiego> FUautotools: you have a peculiar nick.. [13:10:54] <FUautotools> do you want an empty prefix then? [13:11:05] <FUautotools> DonDiego: yes I do [13:11:13] <mru> [ERROR thing @ hex] [13:11:16] <hyc> ugh. now that I'm actually reading log.c, what's with this gratuitous use of strlen(). bleah. [13:11:26] <hyc> careful, you guys are losing your pretty regex [13:11:58] <mru> ^\[[[:space:]]*ERROR [13:13:04] <FUautotools> Do you still want an empty prefix? [13:13:10] <av500> sure, for aling [13:13:12] <av500> gn [13:15:43] <hyc> unrelated to FUautotools' patch, please get rid of strlens. http://pastebin.org/167609 [13:15:47] <BastyCDGS> btw, I just removed the IFF_ANIM1-8/J stuff from my latest patch [13:16:02] <BastyCDGS> since you commented that you can't change the codec ID while decoding anymore [13:16:10] <BastyCDGS> but exactly this is needed [13:18:42] <hyc> oops, off by one http://pastebin.org/167614 [13:19:12] <merbzt1> BastyCDGS: then you need to merge the codecs [13:19:17] <merbzt1> codecid's [13:19:54] <merbzt1> it is then not a separet codec but a frame coding mode [13:20:03] <FUautotools> http://pastebin.org/167617 [13:21:29] <hyc> FUautotools - looks like you've got it. of course, I'm not an actual team member here [13:22:20] <BBB> BastyCDGS: I agree with merbzt1, you probably want to preceed the AVPacket's data with the coding mode byte or something along those lines, and then handle that byte in the actual decoder [13:22:30] <BBB> BastyCDGS: but I ddn't look carefully at the patch yet, hope to do that today [13:32:16] <BastyCDGS> key [13:32:17] <BastyCDGS> okey [13:35:01] <BastyCDGS> preceeding a single byte to AVPacket is probably a bad idea... [13:35:14] <BastyCDGS> it will odd-byte align the actual data [13:35:26] <BastyCDGS> which might be a huge perfomance impact [13:35:32] <BastyCDGS> if it's either read (D)WORD wise [13:36:00] <BastyCDGS> so I'll allocate an int or sth like that [13:36:23] <BastyCDGS> AVPacket->data I meant [13:36:55] <BBB> that's fine also, I guess [13:36:56] <wbs> I don't think you should read such data with operations that require aligned access, on some architectures it's just plain slower, on some it's not permitted at all, and afaik there's no alignment requirement for AVPacket->data [13:37:00] <BastyCDGS> btw, merging of the codecs just done ;) [13:37:09] <BBB> merging codecs = good :) [13:37:31] <wbs> that is, doing unaligned accesses are not permitted, unless you wrap it in something like AV_RB32() etc [13:39:31] <mru> correct, packet data is not required to be aligned [13:39:40] <BastyCDGS> is that even necessary? [13:39:47] <BastyCDGS> isn't there anything like avpkt->flags? [13:39:48] <mru> most compressed data has no internal alignment anyway [13:39:56] <BastyCDGS> where you just have 32 bits to set or sth.? [13:40:19] <wbs> there's no point in speculating in whether reading stuff one way or another is faster/slower since you can't rely on its alignment [13:41:25] <BastyCDGS> int flags; [13:41:34] <BastyCDGS> AVPacket [13:41:53] <BastyCDGS> can I use these for setting the compression type? [13:42:18] <BastyCDGS> or are they used internally? [13:42:30] <BastyCDGS> header file doesn't document it [13:42:36] <mru> you can only use whatever is in the header [13:42:50] <BastyCDGS> this IS in the header [13:42:51] <mru> the decoder must not rely on your demuxer being used [13:43:20] <mru> so you can only set flags defined in the public header [13:43:56] <mru> AV_PKT_FLAG_KEY is the only one currently defined [13:44:50] <BastyCDGS> what about this? [13:44:50] <BastyCDGS> void *priv; [13:45:01] <mru> decoder must not touch that [13:46:07] <BastyCDGS> int stream_index; [13:46:18] <BastyCDGS> is this the frame? [13:46:23] <BastyCDGS> currently playing? [13:46:45] <wbs> no, it's the index of the AVStream within the AVFormatContext that the packet belongs to [13:47:36] <BastyCDGS> sounds useful for something else though ;) [13:48:19] <BastyCDGS> AVCodecContext->sub_id; [13:48:31] <BastyCDGS> Some codecs need additional format info. It is stored here. [13:48:40] <BastyCDGS> sounds like I can put the compression type there... [13:50:52] <lu_zero> wbs: I started putting some stats facility in feng, could you give me your opinion? What you'd like to see there (that's missing) ? [13:51:36] <wbs> lu_zero: is the current stuff available somewhere? (don't see it in git on lscube) [13:51:55] <wbs> lu_zero: generally, the number of current viewers of each stream, perhaps the total bandwidth used [13:52:29] <wbs> preferrably remote accessible through some http api or something similar, but other access may be usable too [13:54:54] <wbs> lu_zero: btw, if you were experiencing weird slowdowns when watching rtsp streams with ffplay for testing different timestamps mechanisms... I found out that it's the ffplay framedrop code that may get triggered by those streams sometimes [13:55:05] <wbs> if running with -noframedrop, the streams run just fine [13:55:37] <wbs> (haven't gathered enough on it to create either a patch or a bug report, though..) [14:01:45] <lu_zero> wbs: uhm you are right [14:02:17] <lu_zero> wbs there is a statistics branch [14:02:54] <wbs> ah, there it is, missed it :-) [14:03:27] <lu_zero> http://cgit.lscube.org/cgit.cgi/feng/log/?h=statistics [14:03:47] <lu_zero> it provides a json if you request /stats through http [14:03:52] <pentanol> hi mru, we talk about disasm dumps avcodec lib when it glitched on arm compiled with uClib here it's... http://rapidshare.com/files/378827339/libavcodec.a.asm.tar.bz2.html there dumps libs which's compiled with optimisation and not. http://codepad.org/Jb6cL5VX [14:04:04] <wbs> that's probably a quite neat and simple interface, I'll have a look in a few days [14:05:02] <lu_zero> I'll add the bandwidth calculation soon (since that's missing [14:05:21] <KotH> omg.. using rapidshare for file exchange... [14:05:34] <KotH> pentanol: we are no warez and pr0n guys [14:05:58] <Kovensky> KotH: rly? [14:06:04] <BastyCDGS> hehe [14:06:06] <KotH> ya rly [14:06:37] <Kovensky> I have heard of at least one pr0n sample what helped fix a codec ;) [14:07:25] <BastyCDGS> tell...which codec? [14:07:25] <KotH> Kovensky: but, do you have a rapidshare pro account? :) [14:07:46] <av500> BastyCDGS: libaa [14:07:46] <KotH> Kovensky: if you dont, rapidshare is just a PITA [14:08:03] <BastyCDGS> and why the sample helped in that ;) [14:08:04] <BastyCDGS> ? [14:08:10] <BastyCDGS> what was the bug? [14:09:30] <pentanol> KotH c'mon ;) I wan't post here link to my servers:) [14:10:05] <Kovensky> KotH: oh, ofc, rapidshare is useless :P [14:10:14] <Kovensky> pentanol: mediafire [14:12:22] <BastyCDGS> btw, shall I provide a patch which adds EHB support to the original codec? [14:12:26] <BastyCDGS> IFF [14:12:44] <BastyCDGS> (requires parsing the CAMG chunk) [14:13:14] <BastyCDGS> and dump an error message if the IFF-ILBM is HAM6/HAM8? [14:13:26] <BastyCDGS> the original code silently let it by [14:14:49] <BastyCDGS> neither EHB nor HAM are IFF-ANIM specific [14:15:06] <BastyCDGS> I could add it to the 100% iff-compliance.patch if desired [14:15:51] <BBB> no no, small patches are easier [14:16:00] <BBB> and that patch was reviewed, you should revise it :) [14:16:28] <BBB> for codec-id, just transmit the whole header along with the frame if that makes it easier [14:20:10] <BastyCDGS> I already adressed the issues of that patch, just didn't re-submit it yet [14:21:09] <BastyCDGS> so I would simply add the CAMG stuff in there (it really fits in there, since EHB is part if IFF-ILBM compliance) ;) [14:21:33] <BastyCDGS> it's ~ 10 lines more [14:24:01] <BBB> you're trying to prevent having to use git/quilt [14:24:05] <BBB> that's not a good idea :) [14:24:15] <BBB> it's painful to start, but it's easier in the long run [14:24:28] <BBB> but for this time just submit the patch as-is, just expect people to tell you you should split it ;) [14:25:00] <BastyCDGS> no I'm tryping to make the IFF-ANIM patch at the end really only dealing with IFF-ANIM itself ;) [14:25:06] <BastyCDGS> EHB is not part of this [14:26:01] <BBB> I know, but that doesn't mean anything else is part of a second patch [14:26:06] <BBB> it means you'll have 3 patch [14:26:06] <BBB> e [14:26:07] <BBB> s [14:26:20] <BBB> didn't you see I committed like 8 patches yesterday? [14:26:24] <BBB> they all touched similar code [14:26:28] <BBB> but each did something else [14:26:30] <BBB> do it's 8 patches [14:26:32] <BBB> not 2, or 4 [14:26:35] <BBB> or 1 :) [14:29:19] <lu_zero> uhmm [14:32:10] <BBB> hi lu_zero [14:32:19] <BBB> will you work on the website for the foundation? [14:35:00] <lu_zero> BBB: if nobody else is up to [14:35:32] <BBB> that's quite evident [14:36:23] <BastyCDGS> what should the website done with? [14:36:31] <BastyCDGS> I can assist with PHP/MySQL experience [14:36:34] <BBB> html, just basic html [14:36:36] <BastyCDGS> HTML too [14:36:41] <BBB> help would be good [14:37:18] <BastyCDGS> and of course with testing various browsers... [14:37:44] <jai> pure html shouldnt be a problem [14:37:48] <BastyCDGS> konqueror (KDE 3/4), firefox 3/3.6, IE 5.5/6.0/8.0 if that's enough... [14:37:49] <BBB> website should be like http://www.mozilla.org/foundation/ [14:37:54] <BBB> simple, straightforward, and pretty [14:37:55] <jai> just stay away from CSS3 [14:38:00] <lu_zero> why? [14:38:05] * lu_zero is all for css3 [14:38:13] * BastyCDGS adds lynx to testing list [14:38:13] <mru> BBB: you call _that_ pretty????!?!? [14:38:21] <jai> lu_zero: because of ie [14:38:21] <BBB> mru: better than ffmpeg.org [14:38:28] <jai> unless you dont care about ie compatibility [14:38:35] <mru> I strongly disagree [14:38:35] * lu_zero doesn't [14:39:07] <lu_zero> anyway [14:39:24] <jai> also, wouldnt you need some artwork to work with? [14:40:07] <BastyCDGS> only if we won't make it text-only ;) [14:40:31] <BBB> you guys provide artwork [14:40:32] <BBB> :) [14:40:45] <BBB> this is actual work, yes [14:40:51] <BBB> it's not a 10-minute hack [14:41:12] <jai> of course :) [14:41:32] <lu_zero> I could check if the people that usually makes design for me would be up for this task [14:41:53] <BBB> excellent [14:41:57] <lu_zero> and how much they would like to be paid or not [14:42:18] <BBB> we can consider paying a little, but it's mostly not-for-profit [14:42:38] <jai> minimal is good -> http://www.sinatrarb.com/ as an example [14:44:07] <lu_zero> uhmm [14:44:30] * lu_zero calls [14:47:54] * KotH calls the men in white [14:50:06] <BastyCDGS> lu if you need help don't hesistate to ask me on specific stuff [14:50:53] <lu_zero> ok, hopefully by sunday I'll have some estimates [14:51:42] <BastyCDGS> uhm who did wrote this? [14:51:44] <BastyCDGS> length = -value + 1; [14:51:54] <BastyCDGS> should be: length = ~value; [14:52:09] <lu_zero> BastyCDGS: the website will be probably pure xhtml+css2/3 [14:52:23] <wbs> the former is much more readable, depending on context of course [14:52:34] <BastyCDGS> RLE decoding [14:52:39] <wbs> if it isn't critical for performance [14:53:20] <BastyCDGS> it's the original IFF byterun1 decoder [14:53:24] <BastyCDGS> and it's in a loop [14:53:43] <BastyCDGS> will just provide a patch for this line... [14:54:57] <lu_zero> benchmark it as wel [14:54:58] <lu_zero> l [14:55:17] <BastyCDGS> not eax [14:55:23] <BastyCDGS> shall be faster than [14:55:25] <BastyCDGS> neg eax [14:55:26] <BastyCDGS> inc eax [14:55:49] <BastyCDGS> it even stalls the pipeline [14:55:56] <lu_zero> BastyCDGS: keep in mind x86 _isn't_ the whole world [14:56:20] <lu_zero> and gcc might do the change by itself =P [14:56:31] <BastyCDGS> is there REALLY any CPU out there which has NEG but not NOT [14:56:38] <av500> not not not? [14:56:53] <lu_zero> BastyCDGS: I hope all have both =P [14:56:55] <BBB> these are still small changes [14:56:58] <BBB> they're good [14:57:03] <BBB> but how's the anim decoding going? :) [14:57:27] <BastyCDGS> I was stumbling around this when I was fixing the EHB support (I found something still missing) [14:57:40] <BBB> ok... :) [14:57:42] <BastyCDGS> that might also be a cause that the image is garbaged in IFF-ANIM [14:58:30] <BBB> I guess that depends on the frametype... :) [14:59:41] <BastyCDGS> the first image is either raw IFF-ILBM or RLE [14:59:59] <BastyCDGS> but the thing is that in my IFF-ANIM it's a EHB [15:00:26] <BastyCDGS> just was considering that... [15:03:35] <BastyCDGS> just doing a test build [15:03:49] <BastyCDGS> to be on the safe side ;) [15:05:17] <BastyCDGS> btw, optimized similar stuff also [15:05:35] <BastyCDGS> removed a mul in a loop by replacing it with an appreciate add [15:28:37] <mru> hmm, -x+1 != ~x [15:29:23] <BastyCDGS> just noticed that while testing an LBM with it ;) [15:29:30] <BastyCDGS> was the other way around [15:29:57] <BastyCDGS> -x-1 = ~x [15:30:49] <BastyCDGS> anyway then I just apply the mul-out-of-loop-replace-with-add-patch [15:32:39] <BastyCDGS> replaced also some * and / by << and >> [15:32:51] <BastyCDGS> yes I know the compiler does it but when I do this in RIFF... [15:39:11] <BastyCDGS> btw, while doing this I had a really great idea of EHB support making it as simple as adding just 4-5 lines in total [15:39:19] <BastyCDGS> and also without that change in iff.h [15:39:33] <BastyCDGS> in fact there are 2 possibilities in doing that [15:39:54] <BastyCDGS> one smart and one fast (but a little bit more error prone) [15:40:28] <BastyCDGS> the more error prone differs in that it doesn't have to read the CAMG chunk [15:40:46] <BastyCDGS> it just checks if the length if CMAP is either EHB or normal compatible solely it's length [15:41:03] <BastyCDGS> the smart one would also read CAMG and do the EHB check only if the normal length doesn't fit [15:41:07] <BastyCDGS> which one you would prefer? [15:41:15] <BastyCDGS> (we'll need CAMG later anyway for HAM support) [17:31:56] <DimStar> Good evening everybody. Just wanted to let you all know that my latest patch for libswscale built completely and the post build check did no longer fail... would be great if the patch could be reviewed and, if considered useful, applied to trunk. [17:34:54] <jai> send it to the ml [17:36:23] <merbanan> mmm food [17:37:37] <DimStar> jai: yacks :) I need to subsribe there again :) [17:37:56] <DimStar> it's typically a 'too high volume' for a non active follower... [17:38:05] <DimStar> but I'll do it :) [17:38:18] <mru> you can subscribe and turn off delivery [17:38:25] <av500> DimStar: your mailer will hapilly file it away in a dedicated folder [17:38:44] <DimStar> av500: you met my mailer already? :) [17:39:02] <av500> yes, use a stronger password next time [17:39:10] * drv plays the "see if lkml can catch up with gmail size limit increases" game [17:40:15] <mru> I suspect google detect list mail and only store one copy per subscriber [17:40:46] <drv> well, it counts toward my account limit anyway [17:41:17] <mru> how evil of them [17:41:39] <av500> mru: per subscriber? [17:42:09] <mru> eh, scratch that bit [17:42:24] <mru> and _not_ store one copy per subscriber [17:42:30] <av500> gg could subscribe all mls and offer that as a service in gmail [17:49:03] <DimStar> ok.. mail should be flying by... [18:02:34] <mru> too much ifdef [18:59:37] <CIA-7> ffmpeg: michael * r22946 /trunk/libavutil/log.c: [18:59:37] <CIA-7> ffmpeg: Coloring the log with ANSI. [18:59:37] <CIA-7> ffmpeg: Ive checked this on black and white background and found no problem in terms [18:59:37] <CIA-7> ffmpeg: of readability. [18:59:37] <CIA-7> ffmpeg: flames welcome. [19:00:18] <Dark_Shikari> \o/ [19:00:22] <Dark_Shikari> I love you michael [19:00:27] <mru> I HATE YOU MICHAEL [19:00:33] <BBB> lol :) [19:00:48] <dgt84> heh [19:00:52] <BBB> I mean, FLAMEWAR!!!11 [19:01:50] <_av500_> gee, too late to get popcorn [19:02:06] <mru> seriously, I ought to take away his commit rights for a while [19:02:19] <Dark_Shikari> lol [19:02:27] <Dark_Shikari> COMMIT RIGHTS WAR1!11 [19:02:43] <DimStar> commit rights? Can I has it? :) [19:03:19] <jai> sure, give us a meeeellion dollarz [19:04:42] <BBB> that little? [19:04:43] <mru> I feel like strangling someone [19:05:10] <j-b> would some people need some Blu-Ray drives ? [19:05:17] * mru already has [19:05:23] <mru> don't know why [19:08:01] <_av500_> j-b: gimme [19:08:23] <_av500_> i can pick it up in paris [19:08:30] <_av500_> :) [19:09:16] <j-b> _av500_: would you improve lavc ? [19:09:35] <_av500_> err [19:10:38] <jai> hmm, i get a bunch of colored text all over the place [19:11:02] <jai> makes me want to bump up MAX_READ_SIZE [19:11:42] <BBB> j-b: how's libbluray going? [19:11:59] <j-b> BBB: not that bad, but I am still fighting the legal fight [19:12:09] <j-b> BBB: and we have one GSoC student to work on it [19:13:00] <wbs> lu_zero: btw, feng seems to require libnetembryo >= 0.1.2 at the moment, even if the latest release is 0.1.1.. is there any concrete requirement for this? it seems to build just fine with 0.1.1 for me, when I modded configure [19:13:08] <_av500_> j-b: there are ppl more in need than me to give the drive too :) [19:14:25] <lillo55> hi all experts [19:14:29] <j-b> BBB: in fact the issue is that I don't understand a shit of the last "arrêt de la cour d'état" on DADVSI [19:15:25] <_av500_> j-b: quoi? [19:15:34] <lillo55> somebody can help me about VP6 playback on wii mplayerce? [19:16:15] <mru> some people like it obscure... [19:16:21] <j-b> _av500_: http://juriscom.net/jpt/visu.php?ID=1087 [19:17:00] <lillo55> nobody? [19:17:12] <j-b> lillo55: wrong channel :) [19:17:31] <FFmpeg|BBB> j-b: huh? legal fight? [19:17:31] <FFmpeg|BBB> wtf? [19:18:04] <FFmpeg|BBB> (sorry for nick, it's gsoc time) [19:18:36] <merbanan> FFmpeg|BBB: what channel is it ? [19:18:50] <FFmpeg|BBB> #gsoc-dedup [19:18:50] <lillo55> but mplayerce use libavcodec [19:18:56] <FFmpeg|BBB> we're not affected [19:19:23] <lillo55> a part of FFmpeg... [19:19:59] <j-b> FFmpeg|BBB: mainly: "Is distributing the source for a meant to break a DRM, legal or not?" [19:20:13] <FFmpeg|BBB> .. in france [19:20:16] <FFmpeg|BBB> but is that a legal fight? [19:20:20] <FFmpeg|BBB> I didn't know you were in court [19:20:25] <j-b> oh, not yet :) [19:20:30] <Dark_Shikari> lol [19:20:32] <FFmpeg|BBB> so who cares? [19:20:36] <FFmpeg|BBB> give me libbluray :) [19:20:53] <FFmpeg|BBB> maybe I should do that next [19:20:57] <FFmpeg|BBB> can you send me the bluray drive? [19:21:00] <FFmpeg|BBB> :-p [19:21:00] <j-b> FFmpeg|BBB: I do care. And I can give you a tarball whenever you want [19:21:08] <FFmpeg|BBB> we'll see who sues me first [19:21:15] <FFmpeg|BBB> actually, before you do, let me talk to sflc and see if that's ok [19:21:37] <FFmpeg|BBB> I might be in trouble here for contributing to source even if I don't personally distribute it... then again, a commit is a distribution also [19:21:48] <j-b> but, in fact, France has a stupid law where they made a mistake and should allow us to distribute binaries+keys [19:23:37] <wbs> lu_zero: the json stats look quite ok, but gives e.g. clients: 3 even if there is only one client watching [19:26:10] <merbanan> BBB: so all gsoc is fine and dandy ? [19:26:58] <_av500_> all students quali-fried? [19:28:40] <merbanan> yupp, really fried [19:52:13] <BBB> merbanan: yes, I think so [19:57:42] <_av500_> \\\ooo/// color errors [19:57:59] * _av500_ forced his netbook to compile ffmpeg [20:04:50] <mru> poor netbook [20:05:28] <_av500_> it survived [20:05:42] <_av500_> it even started to play ffserver [20:05:58] <_av500_> thought it was mp3 [20:06:06] <_av500_> we have no elf probe? [20:06:12] <_av500_> or antiprobe [20:09:12] <jai> BastyCDGS: i'd really suggest spending time working on a new decoder instead of these "optimizations" :) [20:09:16] <BBB> BastyCDGS: mru simply wants you to look at disassembly before and after your patch [20:09:33] <BBB> and yes, this decoder is obscure enough for us to not care too much about optimizations [20:09:53] <jai> the maintainer might consider readability more important [20:10:06] <BBB> if amiga can decode it, then surely even the best-fucked-up arm processor can decode this crap on cell phones nowadays [20:10:11] <BBB> unoptimized [20:10:46] <jai> as far as all those anim packing modes, we care about supporting as many [20:10:52] <jai> as possible [20:12:00] <BastyCDGS> amiga decodes this by hardware mostly [20:12:18] <BBB> oh, btw, AV_LOG_ is a log level set per message [20:12:23] <BBB> so AV_LOG_SILENT wouldn't make much sense [20:12:27] <BBB> it'd mean "never print me" [20:12:40] <BBB> you're wondering about what the default log level would be, which is the -v option to ffplay/ffmpeg [20:12:46] <_av500_> BBB: it is printed in transparent with latest patch [20:13:45] <jai> also, i'll reiterate my opinion, the compiler should be able to convert those into shifts by itself [20:13:49] <BastyCDGS> jai, you're right...but doing this had a nice side effect [20:14:02] <BBB> jai: / != >> [20:14:09] <jai> BastyCDGS: which is? [20:14:10] <BastyCDGS> for me, I found a much better way to handle EHB stuff than current patch [20:14:13] <BBB> jai: -9/2 is not the same as -9>>1 [20:14:26] <jai> BBB: i know, i meant the unsigned ones [20:14:36] <BastyCDGS> yes but I were optimizing signed stuff also ;) [20:14:53] <BastyCDGS> number of bpp can't be neg for example [20:14:55] <BastyCDGS> so it's safe [20:15:27] <BBB> we should make such vars unsigned [20:15:28] <BBB> anyway [20:15:29] <BastyCDGS> btw, I did a git clone now [20:15:30] <BBB> ... [20:15:46] <jai> make it unsigned then :) [20:15:49] <jai> yeah [20:15:49] * BastyCDGS likes the git output in that [20:15:50] <BBB> BastyCDGS: focus on the decoder... these formats are obscure enough for us to not bother too much with performance [20:16:11] <BBB> performance is more important for formats such as h264 [20:16:13] <BastyCDGS> much better than SVN: A blabla.c [20:16:15] <BastyCDGS> etc. [20:17:56] <BastyCDGS> just read your comments on my newest patch [20:18:19] <BastyCDGS> about that optimizer stuff, you're right it runs the same code...but not 100% [20:18:44] <BastyCDGS> there is somewhere a thing like an if checking if it's a / [20:18:49] <mru> no [20:18:51] <mru> there's not [20:19:28] <BastyCDGS> there has to be, otherwise the compiler wouldn't know at all that a division is requested, right? [20:20:01] <mru> there's of course the frontend parser [20:20:22] <mru> which feeds an internal-representation tree to the optimiser [20:20:38] <mru> the optimiser consists of several passes [20:20:57] <BastyCDGS> that's new in GCC 4 yes, but old GCC 2 was different on this...or do you mean sth. different than the vectorize-tree? [20:21:13] <mru> high-level passes do things like CSE, loop permutations, DCE [20:21:41] <mru> the overall design of gcc hasn't changed since gcc2 [20:22:05] <mru> I don't know why they put 'tree' in the name of a few new flags [20:23:07] <mru> after the high-level optimisations RTL optimisations are performed [20:23:10] <BastyCDGS> btw, concerning readability...generally you're right, but we're dealing here with bit-planes [20:23:18] <BastyCDGS> so shifting is more "natural" here... [20:23:23] <mru> these are low-level transformations on pseudo-instruction level [20:23:26] <osaft> tree->binary-search-tree->log(n)->fast->gcc==fast ;-) [20:23:29] <BastyCDGS> amiga uses bit-planar mode not chunky [20:24:05] <BastyCDGS> and so does IFF-ILBM ;) [20:24:13] <mru> finally the pseudo-instructions are turned into assembler [20:24:25] <mru> this is where / can turn into >> and vice versa [20:25:36] <mru> for each RTL insn it looks for an equivalent sequence where each step has a direct asm representation [20:25:39] <BastyCDGS> I just personally think that code dealing with bits should use bit like instructions (even in C src) [20:25:55] <BastyCDGS> and << & >> fall into this category... [20:26:00] <mru> but these are numbers [20:26:05] <mru> not bitfields [20:26:22] <bcoudurier> hi guys [20:26:54] <Dark_Shikari> hi bcoudurier's onjoin script [20:27:29] <BastyCDGS> I didn't mean the data type bitfields [20:27:29] <BBB> mru: he's right that in this case, / is not turned into >> because all these numbers are signed [20:27:36] <BBB> mru: which is a bug, they should be unsigned [20:27:38] <mru> maybe we should fix that then [20:27:49] <mru> fix the cause, not the symptom [20:27:52] <BBB> but I agree generally these aren't worthy optimizations [20:28:34] <BBB> loren wrote the fft asm right? now that's optimizations [20:28:35] <BastyCDGS> simply switching some stuff to uint can also cause perfomance lecks because you have then do sign extensions etc. [20:28:38] <BBB> I mean, wtf :) [20:28:57] <BastyCDGS> but I'll look at this and convert the stuff to unsigned too if that causes no side effects [20:29:05] <BBB> BastyCDGS: they're low-level... think higher-level :) [20:29:34] <wbs> generally, premature optimization is the root of all evil, as they say [20:29:40] <BBB> I'll tell you that the fft code in ssewhatever is about 10x faster than the original. you'll never, EVER accomplish a 10x speedup with micro-optiizations [20:29:43] <jai> yes, as i said earlier, make them unsigned [20:29:58] <wbs> first implement whatever you're supposed to implement, then we can start looking at tweakings later [20:30:02] <jai> that's acceptable [20:30:03] <Dark_Shikari> BBB: but the best way to make something 10% faster is to make it 0.1% faster 100 times. [20:30:12] <Dark_Shikari> Of course, that's stupid for a new codec [20:30:21] <Dark_Shikari> that has huge speedups you could get even ignoring micro-ops. [20:30:22] <Dark_Shikari> *opts [20:30:28] <BBB> Dark_Shikari: no, file decoding got 10x faster [20:30:36] <mru> Dark_Shikari: not if a simple restructuring makes it 5x faster [20:30:45] <Dark_Shikari> mru: that was my point [20:30:51] <BBB> Dark_Shikari: just by enabling yasm fft [20:30:51] <Dark_Shikari> for a new codec that approach is dumb [20:30:54] <BBB> I was like "wtf" [20:31:06] <mru> Dark_Shikari: for old ones too [20:31:15] <Dark_Shikari> mru: "new" means "hasn't been optimized by sane people yet" ;) [20:31:20] <mru> ah [20:31:33] <superdump> immature in terms of development [20:32:23] <BastyCDGS> please also don't forget I have to study this code carefully right now though (since I'm new to ffmpeg devel) [20:32:32] <BBB> that's fair [20:32:35] <BastyCDGS> so when scrolling around it I just done it on the fly ;) [20:32:53] <mru> try to break that habit [20:33:03] <BBB> yeah, it distracts [20:33:07] <wbs> you don't need to modify _all_ code you see [20:33:19] <wbs> every modification has to go through peer review anyway, keep it to the ones that are worthwhile [20:33:20] <BBB> you'll find so much of ffmpeg you could optimize with no general effect at all... [20:33:30] <BBB> focus on these parts that matter [20:33:40] <BastyCDGS> well I would suggest for now, that we finish that discussion for now (either you accept the patch or not) and go on [20:33:51] <BastyCDGS> i have some questions about git right now, which are more important [20:33:57] <BBB> ask :) [20:34:12] <BastyCDGS> I have now a clean git repository [20:34:14] <BBB> also, for "performance optimizations", eep our rules in mind: we need timer info from before and after the patch [20:34:48] <BastyCDGS> one question is... [20:35:08] <BastyCDGS> makes it a difference to git, if I edit files in the base repo or apply a patch which would do the same? [20:35:24] <CIA-7> ffmpeg: bcoudurier * r22947 /trunk/libavformat/mpegts.c: [20:35:24] <CIA-7> ffmpeg: Disable LATM AAC in mpegts, this is not supported and produce too many [20:35:24] <CIA-7> ffmpeg: bug reports. Also warn the user about it. [20:35:30] <BBB> read doc/optimization.txt [20:35:32] <BBB> while you're at it [20:35:36] <BBB> it's a good read, though a tad old [20:38:18] <Dark_Shikari> if you like micro-optimizations, x264 always welcomes those ;) [20:38:30] <Dark_Shikari> though most of x264 has already been micro-optimized with a fine-toothed comb [20:38:40] <Dark_Shikari> (and we still reject microopts that make things much uglier for little benefit) [20:38:55] <BastyCDGS> I'll explain why I do this stuff like replace / 2 by >> 1 etc. that means where my behaviour for this originates [20:39:18] <mru> old compilers? [20:39:19] <BastyCDGS> this is because almost all C compilers I used during amiga days didn't do this stuff [20:39:21] <Dark_Shikari> well every systems programmer has that instinct [20:39:40] <mru> compilers are much better now [20:40:04] <mru> if you want to optimise stuff, you should always start with oprofile [20:40:13] <Dark_Shikari> well, int / 2 is still not just one instruction [20:40:18] <Dark_Shikari> unless the compiler can prove the value is always positive [20:40:21] <Dark_Shikari> e.g. as in a loop index [20:40:27] <mru> or by being unsigned [20:40:28] <CIA-7> ffmpeg: michael * r22948 /trunk/libavutil/log.c: [20:40:28] <CIA-7> ffmpeg: Disable ANSI color code until we figured out how to detect ANSI support in [20:40:28] <CIA-7> ffmpeg: the used terminal. [20:40:33] <Dark_Shikari> I say int [20:40:34] <Dark_Shikari> not uint [20:40:45] <BastyCDGS> another point to mention out [20:40:50] <mru> which is why using unsigned variables is often good [20:40:54] <mru> often but not always [20:40:56] <BastyCDGS> the following will fail for example on m68k: [20:40:57] <Dark_Shikari> uints have their own problems as local vars [20:41:00] <Dark_Shikari> multiplies are slower [20:41:00] <BastyCDGS> 16777216 / 4 [20:41:07] <mru> Dark_Shikari: depends on cpu [20:41:10] <Dark_Shikari> oh x86, at least [20:41:11] <Dark_Shikari> *on [20:41:12] <BastyCDGS> for both signed/unsigned [20:41:34] <mru> if you only care about the low half of the result it doesn't matter [20:41:40] <BastyCDGS> if and only if 4 is short [20:41:41] <Dark_Shikari> yeah, but just tell the compiler that [20:41:52] <mru> int x = y * z; [20:41:59] <mru> there, don't care about high 32 bits [20:41:59] <BastyCDGS> the reason is that the 68000 just had a 32/16 bit division [20:42:13] <Dark_Shikari> mru: you sure the compiler is smart enough? [20:42:20] <BastyCDGS> if the result is larger than 32k - 1 (signed) or 64k - 1 (unsigned) it doesn't put any result at all [20:42:21] <mru> many modern CPUs don't have integer division at all [20:42:25] <mru> Dark_Shikari: sure [20:42:38] <BastyCDGS> it just sets the overflow bit in that case [20:42:55] <mru> Dark_Shikari: gcc is much too stupid to use 16-bit mul when it could though [20:43:13] <BastyCDGS> but 16777216 >> 2 does NOT fail [20:43:19] <mru> arm has both signed and unsigned long mul [20:43:37] <Yuvi> mru: it does sometimes, but it's regressed significantly since 4.2 [20:43:42] <BastyCDGS> an m68k compiler will therefore consider 16M / 4.w different than 16M >> 2 [20:43:52] <mru> Yuvi: there's a reason for the MUL16 macro [20:43:52] <Dark_Shikari> mru: yup, you're right [20:44:05] <Dark_Shikari> it uses imul instead of mul [20:44:13] <Dark_Shikari> for a func that takes uint32_t x2 and multiplies to uint32_t output [20:44:46] <BastyCDGS> and I think there are similar caveats for other CPUs than m68k too... [20:45:01] <mru> try not to think of m68k [20:45:12] <mru> x86 and arm are the important ones today [20:45:33] <Dark_Shikari> wow. [20:45:36] <Dark_Shikari> gcc 3.4 optimizes this correctly [20:45:37] <Dark_Shikari> uint32_t func( uint32_t x, uint32_t y ) [20:45:38] <Dark_Shikari> { return ((uint64_t)x * y) >> 32; } [20:45:42] <mru> wow [20:45:43] <BastyCDGS> m68k is just ONE example I know where such strange stuff can happen, there probably plenty of others [20:45:54] <Dark_Shikari> the function is four instructions: [20:45:56] <Dark_Shikari> load y off stack [20:46:00] <Dark_Shikari> mul [x] [20:46:03] <Dark_Shikari> mov eax, edx [20:46:03] <BastyCDGS> gcc even uses rotation instruction [20:46:03] <Dark_Shikari> ret [20:46:16] <Dark_Shikari> it's literally impossible to use fewer instructions [20:46:20] <BastyCDGS> when you do (x << 5) | (x >> 3) and x is unsigned short [20:46:42] <Dark_Shikari> mru: it also works if I do, say >> 31 [20:46:44] <Dark_Shikari> still only 4 instructions [20:46:49] <Dark_Shikari> move off stack, mul, shrd, ret [20:46:54] <Dark_Shikari> I'm surprised [20:47:32] <Dark_Shikari> it is pretty nice how x86 can do arbitrary 32x32->32 with any shift in two instructions. [20:47:33] <mru> apparently it fits nicely into gcc's rtl [20:47:47] <mru> anything that's hard to express in rtl falls apart easily [20:47:51] <Dark_Shikari> heh [20:48:09] <mru> have you looked at that stuff ever? [20:48:09] <BastyCDGS> btw, regarding that unsigned vs. signed stuff, when I look now on this, should I replace >> 1 etc. with / 2 again then? [20:49:06] <Dark_Shikari> btw mru , my latest annoyance is that attribute ((pure)) doesn't work with function pointers [20:49:10] <Dark_Shikari> but attribute ((const)) does [20:49:11] <Dark_Shikari> for no apparent reason [20:49:42] <mru> we need a new compiler [20:49:59] <Dark_Shikari> well, we need a compiler that we can give more information [20:50:09] <Dark_Shikari> mru: see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43827 [20:50:28] <Dark_Shikari> it seems rather hard to tell gcc "this dsp function pointer doesn't fuck with things, don't reload every value from memory after calling it" [20:50:52] <mru> s/intrinsic/attribute/ [20:51:12] <Dark_Shikari> aren't attributes a type of intrinsic? [20:51:39] <mru> intrinsics are the function-like things we're not supposed to use [20:51:45] <Dark_Shikari> lol [20:52:03] <_av500_> why does looking at bugzilla feel like looking at a 747 cockpit? [20:52:20] <Dark_Shikari> gcc devs do seem to be getting better though [20:52:25] <Dark_Shikari> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43845 reported this the other day [20:52:25] <mru> I'm sure a 747 is easier to fly [20:52:38] <Dark_Shikari> simple test case created, patch made, and committed in like a day or less [20:52:49] <Dark_Shikari> makes ffmpeg bugtracker look like a river of molasses during the winter [20:53:19] <mru> I've fixed ffmpeg bugs in less than an hour [20:53:27] <Dark_Shikari> sure, but most random segfaults don't get fixed in a day [20:53:30] <Dark_Shikari> on the tracker [20:53:44] <mru> one reason is poor quality of bug reports [20:54:34] <Dark_Shikari> look at how awful my bug report was. no simple reduced test case, just a massive mess of a file [20:54:49] <mru> didn't read the details [21:05:39] <BastyCDGS> ehm, someone read my question above? [21:05:47] <BastyCDGS> also the one regarding git? [21:07:47] <Dark_Shikari> bah. gcc, die. [21:07:49] <Dark_Shikari> sub [esp+0x21c],eax [21:07:49] <Dark_Shikari> sub [esp+0x220],edx [21:07:49] <Dark_Shikari> mov ebx,[esp+0x21c] [21:07:49] <Dark_Shikari> mov esi,[esp+0x220] [21:08:52] <mru> does it need the values in memory later? [21:09:29] <Dark_Shikari> no, but if it isn't keeping them on the stack I guess it does need to store them again [21:09:33] <Dark_Shikari> that is one way to do it... [21:09:41] <Dark_Shikari> actually I wonder how x86 handles that sort of code idiom [21:09:46] <Dark_Shikari> er, *is keeping them on the stack [21:09:48] <Dark_Shikari> instead of in registers [21:10:23] <mru> it might need the registers for something else in between [21:10:42] <Dark_Shikari> that actually makes sense, the original idea [21:10:48] <Dark_Shikari> that it needs to store them so that later it can clobber those registers [21:10:48] <mru> but load/sub/store should of course be faster than load/sub/store/load [21:11:23] <Dark_Shikari> hmm, actually, gcc uses this idiom a LOT [21:11:41] <mru> it's less code [21:11:42] <Dark_Shikari> add to loop index in memory, load it, compare to max value [21:11:48] <mru> if you don't care about scheduling it looks better [21:11:51] <Dark_Shikari> this eliminates the store [21:12:04] <Dark_Shikari> I suspect load-store forwarding eliminates most of the overhead [21:13:13] <Dark_Shikari> I'm not sure why it uses "add" instead of "inc" though [21:13:22] <Dark_Shikari> (no it doesn't use the flags) [21:18:31] <j-b> __gb__: did you see VDADecoder ? Do you want a mac? [21:20:37] <CIA-7> ffmpeg: mru * r22949 /trunk/libavcodec/arm/rdft_neon.S: [21:20:37] <CIA-7> ffmpeg: ARM: fix build for darwin/iphone [21:20:37] <CIA-7> ffmpeg: References to external symbols in asm code need prefixes. [21:21:27] <astrange> i've seen vdadecoder but don't have a supported gpu [21:23:43] <BBB> does that work on the iphone? [21:24:14] <BBB> BastyCDGS: yes, revert these changes for now [21:24:24] <BBB> BastyCDGS: learn to use git so you can keep them as a private patch [21:24:28] <mru> BBB: I doubt it [21:24:32] <BBB> BastyCDGS: as for git, I have no idea, ask others :) [21:24:39] <BBB> mru: :( [21:24:45] <BBB> that's like the coolest use case [21:24:49] <mru> they seem to keep iphone and macos just different enough to really annoy people [21:25:02] <BBB> but I guess it fits with the "you should use quicktime" principle [21:25:29] <_av500_> does new iphone rulez allow .S at all :) [21:25:46] <_av500_> it was c, c++ and obj-c only... [21:25:52] <Dark_Shikari> _av500_: worse [21:25:53] <astrange> iphone doesn't have quicktime or low-level decode of any form [21:25:57] <Dark_Shikari> the language it's "originally written in" [21:26:00] <Dark_Shikari> or actually [21:26:04] <Dark_Shikari> I think it was originally conceived in [21:26:12] <mru> _av500_: the code was originally written in C [21:26:15] <Dark_Shikari> which means that they are making a judgement on the nature of human conciousness [21:26:16] <astrange> its only video playback api is hw accelerated though [21:26:16] <mru> I translated it to asm [21:26:37] <_av500_> mru: pah, i bet you started with a flash mockup [21:26:39] <astrange> and you can figure out the privateframework prototypes by looking at VideoDecodeAcceleration if you want [21:26:57] <mru> _av500_: yeah, I spent a week taking out all the ifdefs [21:27:20] <_av500_> mru: anyway, u are tainted as you saw fl src [21:27:44] <_av500_> you can never put your stuff in app store [21:27:53] <_av500_> no that you want to... [21:28:46] <mru> Dark_Shikari: did you see the ifdef-fest I posted earlier? [21:31:04] <Dark_Shikari> ? link [21:31:08] <mru> http://pastie.org/928309 [21:31:31] <Dark_Shikari> what is this from [21:31:34] <mru> there's another 700k lines where that came from [21:31:41] <mru> flashlite [21:31:54] <Dark_Shikari> er, are you supposed to be posting that code? =p [21:31:58] <mru> no [21:32:11] <Dark_Shikari> teeeechnically the channel is logged, etc [21:32:36] <_av500_> mru: you should post pngs [21:32:52] <_av500_> in comic sans [21:35:34] <BastyCDGS> mru, another thing I could mention...that's why I did smaller stuff today, don't forget my normal work days started today [21:36:25] <BastyCDGS> tomorrow I have special preparation lessons for exam [21:37:02] <BastyCDGS> but at weekend I will concencrate on decoding stuff ;) [21:37:56] <BastyCDGS> I'm pretty tired right now, so I'ld be glad when you answer the git questions, so I can really use git then [21:38:08] <BastyCDGS> so patching problems are solved finally ;) [21:40:11] <FUautotools> What kind of gibberish was committed for "colour messages"? [21:41:27] <FUautotools> no wonder people bitched (other than breaking) [21:41:52] <pentanol> hi, I'm back, http://www.mediafire.com/?gwdimv3nmdv there diasm for optimized and not avcodec for arm uClib [21:44:30] <CIA-7> ffmpeg: jbr * r22950 /trunk/libavcodec/ac3dec.c: [21:44:30] <CIA-7> ffmpeg: ac3dec: return smaller of buf_size and frame_size instead of always returning [21:44:30] <CIA-7> ffmpeg: frame_size. [21:47:37] <pentanol> mru you there? [21:48:11] <BastyCDGS> he seems to be busy doing some coding stuff probably [21:48:19] <BastyCDGS> or reviewing patches who knows ;) [21:48:46] <mru> if it's about that arm problem, please try to create a minimal test case that fails [21:50:34] <pentanol> test case? [21:51:56] <BastyCDGS> btw, another nice optimization manual on x86 asm and C as well as C++ [21:51:58] <BastyCDGS> http://www.agner.org/optimize/#manual_cpp [21:52:09] <BastyCDGS> just in case you didn't knew the page yet [21:56:55] <pentanol> just guessing, is that might be crashed in lrink, that's from math lib [22:08:52] <pentanol> what means test case? in crached when I start ffmpeg; here ... avcodec_opts[i]= avcodec_alloc_context2(i); [22:09:41] <BastyCDGS> ok, I'll say good night for now and have you nice dreams [22:09:41] <mru> I mean a small stanalone piece of code that exhibits the error [22:10:09] <BastyCDGS> mru, if you want to answer my questions, either write me a mail or next time here [22:10:41] <BastyCDGS> I hope to get here tomorrow evening at least [22:17:28] <BBB> BastyCDGS: also search google for git-questions, not all of us are git-experts [22:17:33] <BBB> at least I'm not :) [22:18:12] <BastyCDGS> it's just that I don't want fiddle hours around with git just to get in my patches I already did [22:18:22] <BastyCDGS> thus not running in the same problem as I had with SVN ;) [22:19:06] <BastyCDGS> who's the best person here to ask stuff regarding git? [22:19:57] <mru> just ask [22:20:02] <Dark_Shikari> don't ask to ask [22:20:02] <mru> if anyone knows they'll answer [22:21:52] <BastyCDGS> okey [22:22:03] <BastyCDGS> so sleep well then...;) [22:22:25] <BastyCDGS> I'd better off now, otherwise I risk falling on the keyboard [22:22:36] <BastyCDGS> so just don't wonder if you suddenly read: fhsdfiuhsdsu :D [22:22:50] <mru> is that a new sssse5 instruction? [22:23:18] <pentanol> mru http://codepad.org/Jb6cL5VX [22:23:20] <BastyCDGS> no that's AMD 4dnow! [22:23:24] <BastyCDGS> ;) [22:23:52] <mru> pentanol: that doesn't look minimal or standalone [22:24:08] <BastyCDGS> *wavesgoodbye* [22:24:21] <pentanol> with optimisation it said av_set_number2 done, and not optimisation it said few times o_0 %i \n" ,ret) [22:24:37] <pentanol> ok [22:24:53] <mru> standalone means it contains a main() function so it can be compiled and run [22:25:06] <mru> minimal means if anything is removed from it, it doesn't show what it's supposed to [22:33:13] <pentanol> yes I got it;) http://codepad.org/lJ0hJjLY [22:33:47] <mru> that's not what I meant [22:34:24] <mru> find the function that fails, copy that out and trim it down until only the failing part remains [22:36:24] <pentanol> here can be dependencies, then it's time... [22:36:45] <mru> time that I don't have [22:36:50] <mru> want your problem solved or not? [22:37:37] <pentanol> that been affirmation [22:37:51] <pentanol> I will post it... [22:37:54] <pentanol> I mean;) [23:09:43] <Yuvi> mru: http://pastie.org/930680 <- does gcc save d8/d9 for you? [23:11:54] <Yuvi> nm, forgot -mfloat-abi [23:14:04] <Yuvi> heh, gcc doesn't handle q clobbers as expected [23:16:26] <mru> known bug [23:16:31] <mru> don't use inline asm with neon [23:16:37] <mru> it's a recipe for disaster [23:18:06] <Yuvi> so I shouldn't report it? [23:18:21] <mru> I'm surprised nobody has [23:18:27] <mru> it's been known for years [23:18:40] <mru> I assumed it was just one of those things they ignore [23:18:41] <Yuvi> well http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43860 [23:19:25] <mru> am I the only one who thinks the title is misplaced in that page? [23:19:27] <Yuvi> I think it's mainly because they convert d and q registers to single s clobbers [23:20:25] <Yuvi> only noticed because I"m trying to fix clang+neon inline asm [23:22:57] <Yuvi> by single s clobbers, I mean d8 -> s16 only, it doesn't explictly mark s17 [23:24:48] <mru> and then save/restore the containing d reg? [23:25:14] <Yuvi> I think so [23:25:19] <Yuvi> apparently someone reported it last month [23:25:24] <Yuvi> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43440 [23:30:52] <mru> and as usual they refuse to fix the easy case because there'd still be a rare complicated case left

1 0

IRC log for 2010-04-21
by irc＠mansr.com 22 Apr '10

22 Apr '10

[00:00:08] <peloverde> I told you [00:00:09] <bcoudurier> then you started complaining about parsing, chain demuxing or whatever [00:00:32] <bcoudurier> I'm trying to _fix_ things here [00:00:36] <peloverde> (1024-64*frame_length_flag)/nominal_sample_rate [00:00:45] <bcoudurier> and since these issues are _very long_ standing [00:00:59] <bcoudurier> nobody can argue for the clean way anymore [00:01:10] <bcoudurier> we need to make things working [00:01:43] <peloverde> we've tried to make things work before and it never went anywhere [00:01:50] <peloverde> making things work is a waste of time [00:02:00] <bcoudurier> what ? [00:02:01] <peloverde> I'd rather work on what's feasible in this disfunctional community [00:02:09] <bcoudurier> here we go [00:02:17] <bcoudurier> I don't believe you [00:02:20] <peloverde> We've discussed these same issues dozens of times since i've been here [00:02:27] <bcoudurier> I never seen any latm stuff working [00:02:32] <bcoudurier> except samsung [00:02:39] <peloverde> google the ML archives for "Paul Kendall" [00:02:49] <bcoudurier> that doesn't work [00:03:09] <peloverde> that was the LATM discussion [00:03:10] <bcoudurier> besides, it's not you [00:03:19] <peloverde> it went nowhere [00:03:20] <bcoudurier> I don't care about the discussion personally [00:03:26] <janneg> bcoudurier: Paul's patches are working for the streams he sees [00:03:30] <bcoudurier> I want a patch that make it _work_ [00:03:34] <bcoudurier> not for mine [00:03:45] <janneg> bcoudurier: and samsung uses one of his patches [00:03:48] <peloverde> then write a patch that will make it work [00:03:50] <bcoudurier> mplayer did patch faad [00:03:53] <bcoudurier> it _works_ [00:04:00] <bcoudurier> there is nothing to discuss [00:04:08] <peloverde> I thought you just said that it doesn't work [00:04:17] <bcoudurier> faad works [00:04:21] <bcoudurier> paul kendall stuff doesn't [00:04:36] <bcoudurier> or am I confusing both ? [00:04:46] <bcoudurier> paul kendal was bitstream filter stuff right ? [00:04:57] <janneg> paul kendall's patches are using libfaad [00:05:11] <peloverde> Look AAC signaling is super-fucked, the only way to handle things is to make soem assumptions and deocde some streams wrong [00:05:11] <janneg> it was various stuff [00:05:27] <bcoudurier> Re: [FFmpeg-devel] [PATCH] LATM Bitstream Filter & Parser [00:05:30] <peloverde> or use MPEG-Surround [00:05:31] <bcoudurier> ... [00:05:39] <bcoudurier> how is that related to faad ? [00:05:52] <janneg> the bitstream filter was not working that well iirc [00:05:54] <peloverde> ‎I never said it was related to faad [00:05:56] <bcoudurier> peloverde, it's fine if 5% are wronly decoded [00:06:11] <bcoudurier> as long as it's less than faad we are gooc [00:06:15] <janneg> but he has also a libfaad/latm decoder which seems to work [00:06:26] <bcoudurier> ok [00:06:33] <bcoudurier> patched faad for mplayer was the way to go [00:06:41] <bcoudurier> it is IMHO the way to go for ffmpeg as well [00:06:51] <bcoudurier> we will get most of the ts stuff decoded [00:07:14] <bcoudurier> if you want chain demuxing, it's also perfectly fine with it [00:07:17] <bcoudurier> but do it :() [00:07:31] <bcoudurier> and I completely understand that AAC is fucked [00:07:52] <janneg> no libfaad patches necessary, just wrapping around faad. [00:07:55] <bcoudurier> but hell we should try to do the best with that we have [00:08:15] <janneg> the only reason for using faad was missing heaac support in ffaac [00:08:22] <bcoudurier> janneg, that's good enough it seems [00:08:45] <peloverde> Then ask the maintainer to put it in the decoder [00:09:32] <peloverde> we can deal with muxing later [00:09:43] <janneg> paul promised to resubmit it with ffaac support as soon as PS is finished [00:09:54] <peloverde> PS is done [00:10:31] <janneg> nice, I must have missed it [00:10:38] <peloverde> it's not merged [00:10:45] <janneg> ah [00:11:02] <bcoudurier> peloverde, aren't you the maintainer ? :> [00:11:09] <bcoudurier> you should be [00:11:16] <peloverde> MAINTAINERS says otherwise [00:11:33] <bcoudurier> don't you want to be maintainer ? [00:12:02] <peloverde> yeah I suppose [00:12:48] <bcoudurier> then take over :) [00:12:57] <bcoudurier> I'm sure superdump will be ok [00:13:27] <bcoudurier> you deserve it after all the effort you put into it [00:13:51] <peloverde> ok [00:14:03] <peloverde> you or paul or whoever have my blessing to put LATM in the decoder, but patches still need to be reviewed on their individual merits [00:17:39] <mru> a [00:19:58] <janneg> peloverde: I've pinged paul, do you have a publich git tree or patch with PS? [00:21:01] <peloverde> janneg, I can make a git tree for it Monday-ish [00:23:32] <janneg> peloverde: thanks [01:22:56] <saintd3v> peloverde: PS finished \o/ [01:46:44] <hyc> anyone here understand FLV format? [01:47:14] <hyc> I'm seeing a live stream where the packet timestamps are much different from the stamps inside the FLV packets [01:47:32] <hyc> e.g. DEBUG: type: 08, size: 373, pktTS: 99ms, TS: 99ms, bLiveStream: 1 [01:47:42] <Dark_Shikari> "packet timestamps"? [01:47:45] <hyc> DEBUG: type: 16, size: 4845, pktTS: 100ms, TS: -512229559ms, bLiveStream: 1 [01:47:57] <Dark_Shikari> FLV only has one set of timestamps [01:48:03] <hyc> those are two consecutive RTMP packets [01:48:14] <Dark_Shikari> what is "TS" [01:48:14] <hyc> a type 08 packet is an audio packet [01:48:18] <Dark_Shikari> where is it stored? [01:48:27] <hyc> a type 16 packet is FLV in RTMP [01:48:40] <Dark_Shikari> what is TS [01:48:55] <hyc> TS is the timestamp read from the packet data, vs the packet header [01:49:21] <Dark_Shikari> meaning the timestamp in the FLV file itself? [01:49:23] <hyc> comes from bytes 4-7 of the packet data [01:49:25] <Dark_Shikari> Sounds like the muxer is retarded [01:50:49] <hyc> yeah, could be [01:51:06] <hyc> came from here http://stream-recorder.com/forum/rtmpdump-live-stream-problem-please-help-t… [01:51:16] <hyc> you can see it yourself if you're interested [01:51:46] <hyc> the only reason I bothered to check is because he says the flash player plays it fine [01:51:54] <Dark_Shikari> probably it ignores the FLV timestamps [01:53:33] <hyc> hm, yeah. I'll see if I can force the stamps to a reasonable value [02:28:24] <astrange> i feel bad for telling that filter guy to try merging his code into the most complicated parts of ffmpeg [03:46:38] <bcoudurier> astrange why do you think it should be best in libswscale ? [03:48:54] <astrange> swscale is much better at scaling and transforms than what he posted [03:49:14] <astrange> but i don't know how to do rotation, so i don't know if it can be evaluated with a kernel [04:00:25] <bcoudurier> ah ok [04:27:22] <astrange> http://astrange.ithinksw.net/ffmpeg/VusionFullVuVideoPlayer-intel vp7 decoder in here somewhere, pity they remembered to strip it [04:28:03] <Dark_Shikari> aw. [04:29:01] <Dark_Shikari> what executable format is it? [04:30:36] <astrange> macho i386 [04:30:47] <astrange> browser plugin [04:31:11] <astrange> http://www1.vusion.com/showcase.php this should autodownload a windows plugin [04:37:46] <thick_mcrunfast> Hey there! Just asked a question in #ffmpeg that should have been here; Essentially, I'm writing an mp4 carver in Python and I have been unsuccessful at finding any kind of documentation on the mdat atom [04:37:57] <Dark_Shikari> astrange: doesn't even use ssse3 :/ [04:38:15] <Dark_Shikari> btw, big_mclargehuge here wants a copy of the ISO media spec [04:38:23] <Dark_Shikari> er, I mean, blast_hardcheese [04:38:24] <thick_mcrunfast> Dark_Shikari: ^^ [04:38:30] <Dark_Shikari> er, I mean roll_fizzlebeef [04:38:53] <thick_mcrunfast> Dark_Shikari: blast_hardcheese is my main, this is my alt, big_mclargehuge is my second alt ;) [04:39:04] <Yuvi> isom is free: http://standards.iso.org/ittf/PubliclyAvailableStandards/ c051533_ISO_IEC_14496-12_2008.zip [04:40:12] <thick_mcrunfast> Yuvi: Looking over it now [04:40:32] <thick_mcrunfast> Thanks for that link, all the stuff I found regarding the spec was like 70+ USD [04:41:05] <Yuvi> part 14 isn't, but you don't really need that [04:42:04] <Yuvi> also if you get an atom viewer it'll help more than reading the spec [05:16:44] <thick_mcrunfast> Yuvi: Ah, good tip [05:16:58] <thick_mcrunfast> I've written something that separates the atoms, but doesn't understand them [05:17:37] <thick_mcrunfast> I've been going through implementing the spec, things have been becoming more and more clear as I go [05:17:44] <thick_mcrunfast> which is very exciting [05:17:47] <KotH> salut [05:53:02] <av500> 'jour [06:36:55] <CIA-7> ffmpeg: conrad * r22927 /trunk/libavformat/movenc.c: movenc: Write nero chapters [06:36:56] <CIA-7> ffmpeg: conrad * r22928 /trunk/libavformat/ (isom.h mov.c): mov: Read QuickTime chapters [06:38:21] <Tjoppen> regarding https://roundup.ffmpeg.org/issue1877 and https://roundup.ffmpeg.org/issue1695 (aac), if the fix ends up just capping the bitrate, then maybe the user should be able to figure out that the bitrate changed? [06:39:20] <Tjoppen> unless I'm mistaken this happens in various cases, where values in AVCodecContext end up slightly modified. if so, then AVCodecContext::bitrate should as well [06:45:01] <Dark_Shikari> well the way x264 does it is that it modifies the parameters in its own internal param struct [06:45:11] <Dark_Shikari> and then has an API call to copy back the current set of parameters [06:46:49] <Tjoppen> ok. I'll just suggest in my roundup thread that the modified bitrate should be left in the context and not hidden away [06:47:19] <astrange> michael didn't like the idea of modifying the context when i tried it once [06:47:25] <Tjoppen> that way I can detect the change and log it [06:47:31] <astrange> i think that's why the mpegvideo encoder dies on invalid values rather than fixing htem [06:47:45] <Tjoppen> the context gets modified by by a lot of encoders though [06:48:06] <Tjoppen> I recall having problems with that, where I had to update my structs in turn [06:48:12] <Dark_Shikari> astrange: ffmpeg should do what x264 does [06:48:14] <Dark_Shikari> encoder_reconfig [06:48:18] <Dark_Shikari> for modifying the context externally [06:58:53] <tetsuo--> How likely is it that the ffmpeg team will accept patches that make ffmpeg compilable on visual studio? [06:59:50] <av500> one liner will get in I guess [07:00:19] <tetsuo--> yeah the patch would have to be simple and to the point [07:00:33] <av500> is it? [07:00:38] <tetsuo--> not currently [07:01:46] <tetsuo--> i think its 20-50 lines spread over 2-10 files currently [07:02:36] <tetsuo--> and i'm convinced some stuff is just plain hacks that need to be beautified into ifdef's [07:02:58] <scaphilo> how do i tell ffmpeg to use h263? h263 is not a full encoder right? It works as a modification to mpeg4 when i understand that correctly. ---- Would -vcodec h263 correct? [07:05:19] <tetsuo--> i have another question about a possible include, how about dxva specific changes to the h264, vc1 and mpeg2 decoders? [07:05:37] <Tjoppen> tetsuo--: we had problems with AV_TIME_BASE_Q in MSVC, due to the syntax it's defined with [07:06:26] <Tjoppen> our solution was to use a constant instead, in the places we needed it [07:06:26] <tetsuo--> i guess we fixed it somehow [07:07:17] <tetsuo--> i'm not to deep into the code as i am not a programmer myself, all i know is that we have been able to compile ffmpeg with msvc for years and i believe we can upstream those patches if/when they are sain [07:07:48] <Dark_Shikari> tetsuo--: no way that will work [07:07:52] <Dark_Shikari> Visual studio uses MSVC [07:07:57] <Dark_Shikari> It might work if you use ICC instead [07:08:00] <Dark_Shikari> but MSVC is not C99-compatible [07:08:07] <tetsuo--> it works [07:08:15] <Dark_Shikari> doubtful, ffmpeg is chock-full of C99 features [07:08:18] <tetsuo--> but i cannot tell you how badly hacked it was to make it possible [07:08:40] <tetsuo--> i know it is, and everyone keeps saying its impossible, and yet we do it every day since 2004 [07:08:40] <Tjoppen> tetsuo--: just diff? [07:08:57] <Dark_Shikari> tetsuo--: Sure, you can do it, but it will be never accepted [07:09:01] <Dark_Shikari> because accepted means banning c99 [07:09:06] <Tjoppen> apart from the problem of figuring out which version/revision you based it off of [07:09:23] <tetsuo--> we update ffmpeg head every 2-4 months [07:09:52] <tetsuo--> Dark_Shikari obviously, thats why i have asked some of the members of my team to extract the patches and look at their sainness [07:10:02] <Dark_Shikari> why not just require ICC? [07:10:04] <Dark_Shikari> problem solved [07:10:11] <tetsuo--> for one its hella expencive [07:10:26] <tetsuo--> and secondly it generates like 300 fatal errors [07:10:48] <tetsuo--> we compile ffmpeg with gcc/mingw for release builds, no problem there [07:10:56] <Yuvi> sainness? [07:11:09] <Dark_Shikari> lol [07:11:20] <tetsuo--> Yuvi: I clean patch that doesnt break any intended behaviour [07:11:23] <astrange> Yuvi: are you making the mov muxer write qt and nero chapters at the same time? [07:11:36] <Yuvi> astrange: yeah [07:12:16] <astrange> well, i guess it doesn't take much space [07:12:22] <tetsuo--> we only use msvc for debug builds, and since its been working flawlessly since 2004 i think there might be some stuff there that could be included in ffmpeg without reverting any of the c99 stuff etc... [07:13:04] <tetsuo--> obviously if all the patch does is replace all the c99 lines with msvc compatible lines its pointless [07:13:52] <Dark_Shikari> why doesn't icc work for debug builds? [07:14:15] <tetsuo--> we get a lot of errors [07:14:42] <Yuvi> btw, changing stuff like (AVRational){1, AV_TIME_BASE} won't be accepted (msvc can't handle that?) [07:15:08] <tetsuo--> Yuvi the patch has to be acceptable on your terms ofcourse [07:15:18] <Yuvi> just forwarning you :) [07:16:52] <av500> tetsuo--: is that patch available somewhere to look at? [07:16:54] <Tjoppen> could be useful for some people though, if you maintain the branch [07:18:30] <tetsuo--> here is our patched source: http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/transform… [07:18:39] <tetsuo--> we dont have the patches seperated out yet [07:18:57] <av500> tetsuo--: and thats against what SVN rev? [07:19:05] <tetsuo--> let me see [07:20:48] <tetsuo--> no rev in the commitlog [07:20:49] <tetsuo--> 02/06/10 17:50:00 (2 months ago) [07:21:19] <tetsuo--> could be off by 1-3 days [07:22:35] <av500> hmm, the fact that you miss files like "configure" makes me think your patch will not be "small" :) [07:23:21] <Tjoppen> not to mention libavformat and libavfilter [07:23:42] <av500> why are e.g. LICENSE missing? [07:24:29] <tetsuo--> we dont use the missing stuff [07:24:44] <av500> you dont use a LICENCE? [07:24:59] <tetsuo--> i have no idea about the missing licence [07:25:47] <tetsuo--> ill ask them to fix that [07:28:09] <tetsuo--> this is interesting: http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/transform… [07:30:34] <tetsuo--> unfortunately he did not make the same listing for ffdshow :( [07:31:58] <av500> tetsuo--: getting a proper diff would be good for a start [07:32:07] <tetsuo--> i agree [07:33:03] <tetsuo--> i'll keep pushing for a proper diff, that matches a recent svn build [07:33:18] <tetsuo--> and then bring it up again [07:35:52] <tetsuo--> i see ffdshow doesnt have the licence file either [07:39:06] <tetsuo--> ill asj them to fix it too [07:39:09] <tetsuo--> ask* [07:40:11] <astrange> ffdshow's installer treats the gpl as a click through license you have to "agree" to [07:40:38] <Dark_Shikari> which is more restrictive than it needs to be, but is at least sufficient [07:40:49] <astrange> which not only is an ffmpeg license violation but is also them violating their own license [07:41:06] <astrange> i don't think being required to agree to the gpl even means anything. it doesn't require the end user to do anything [07:41:23] <Dark_Shikari> well, the GPL is definitely being distributed with the application and displayed to the user [07:41:38] <Dark_Shikari> obviously the clickthrough is stupid and pointless [07:47:39] <av500> no point for enduser to accept gpl [07:48:07] <Tjoppen> the gpl is meant for the benefit of the user, so: yes, there is apoint [07:48:32] <astrange> there's nothing to "disagree" with [07:48:49] <astrange> it's not persuasive or anything, it's just conditional statements [07:48:53] <av500> when you disagree, you are entitled to your money back! [07:48:55] <Tjoppen> sure there is, but then you don't get to use the software. same as any other EULA [07:49:07] <astrange> and as you know from discrete math, those are still true if the condition is false [07:49:27] <astrange> no, you always get to use the software. you can combine gpl and proprietary software and use it [07:49:35] <astrange> you just can't give it to anyone else [07:49:57] <Tjoppen> true. feels like discussing semantics anyway [07:51:28] <Tjoppen> as long as the user is just *using* it, then there's no obligations [08:13:56] <KotH> hoi bilboed-4 [08:14:42] <pJok> mru, ffthreads? [08:17:04] <av500> pJok: supported out of the box on ffos [08:42:32] <peloverde> Hmm just stream copied Pirates3.mov successfully [08:42:40] <peloverde> Anyone else want to try? [08:42:53] <merbzt> omg, a working streamcopy [08:43:29] <peloverde> well with the BSF [08:44:04] <pentanol> mru you here? I made disasm libavcodec lib compiled for arm uClib which given segfault to me. [08:44:17] <wbs> gah roundup is slow [08:46:46] <peloverde> "ffmpeg -i Pirates3.mov -acodec copy copy.adts && ffmpeg -i copy.adts -acodec copy -absf aac_adtstoasc out.mp4" for anyone who wants to try [08:48:52] <peloverde> <bcoudurier> [NULL @ 0x3084d00]Multiple RDBs per frame with CRC is not implemented. Update your FFmpeg version to the newest one from SVN. If the problem still occurs, it means that your file has a feature which has not been implemented. [09:53:25] <Tjoppen> I just remembered that I used to be annoyed that no audio encoder specifies supported_samplerates. perhaps it's time to rectify that [09:54:03] <Tjoppen> .supported_samplerates = (const int[]){44100, 48000, 32000, 22050, 24000, 16000, 0}, <-- works well in the mp2 encoder [09:54:25] <Dark_Shikari> +10000 [09:54:31] <Dark_Shikari> then make it automatically convert if it isn't supported [09:54:34] <Dark_Shikari> Then do the same for channels [09:54:41] <Dark_Shikari> then do the same for sample rate/ sample format /channel combinations [09:54:56] <Dark_Shikari> Then people will no longer be wondering why their mp3 encodes failed with no error message. [09:55:02] <Dark_Shikari> due to their input being 5.1 [09:56:27] <Tjoppen> right, channel_layouts. well, letting the user know for would be good for a start, for which those lists are good [09:56:37] <Tjoppen> -for [10:01:40] <Tjoppen> unless I'm mistaken, a list of combinations would only be needed for certain encoders, right? well, perhaps most. but the basic lists are good for encoders that have fewer limitations, where a list of combinations would become huge [10:03:39] <merbzt> Tjoppen: what do you set for "encoder" supporting random samplerates ? [10:03:59] <Tjoppen> nothing [10:04:12] <merbzt> ok [10:04:24] <merbzt> send a [RFC] I'll support the idea [10:04:29] <Tjoppen> that's what my code assumes at the moment - unless supported_samplerates isn't set, it just goes with whichever setting it has [10:04:49] <Tjoppen> if it fails, and supported_samplerates isn't set (which it never is), it just picks from a list of ones I know usually work [10:06:37] <Tjoppen> might as well - don't have much else to do today. all tickets for today are done, an tests are running happily :) [10:08:57] <Tjoppen> more fun: there's no way to figure out which bitrates are supported either [10:09:28] <Tjoppen> except for brute forcing avcodec_open() via a list of "good" bitrates [10:15:49] <J_Darnley> Add a new field? [10:16:51] <Tjoppen> yeah. supported_bitrates [10:18:52] <Tjoppen> that, and/or define something like struct audio_format { sample_rate, sample_format, channel_layout, bitrate } with "optional" ("anything goes") elements being zero (or SAMPLE_FMT_NONE) [10:19:37] <Tjoppen> struct audio_format *supported_audio_formats [10:20:01] <Tjoppen> lunch time. I'll ponder it a bit [10:20:23] <av500> also take care that e.g. some canon digicams used to record 11024hz :) [11:17:29] <Tjoppen> av500: that sounds like something on the decoder side though. I'm only considering encoders for now [11:18:23] <BastyCDGS> greetings to all, how are u? [11:18:50] <BastyCDGS> a small question, is there a way to pass AVFormatContext->priv_data from demuxer to decoder? [11:19:00] <BastyCDGS> I need that for IFF-ANIM to determine HAM/ECB modes [11:19:05] <wbs> no, you're not supposed to pass such data [11:19:08] <BastyCDGS> and decode the colormap in a correct way [11:19:14] <wbs> since the demuxers and decoders should be decoupled [11:19:17] <BastyCDGS> ok so I have to find another way [11:19:38] <wbs> you need to pack it within AVPacket in some way, or pass it as codec extradata in AVCodecContext->extradata [11:20:15] <BastyCDGS> the current solution has only the colormap directly as extradata, so I have to create a new structure and put cmap data as well as cmap flags I suppose [11:21:04] <wbs> ah, is the colormap something like a palette? I'm not familiar with the handling of palette formats in lavc/lavf, I think that's stored somewhere else than in the extradata field [11:22:11] <BastyCDGS> yes but a amiga specific (planar) version of it [11:22:26] <BastyCDGS> there are special modes like HAM/ECB which have to be handled specially [11:22:38] <wbs> ok [11:23:07] <BastyCDGS> HAM can be compared best to a true color mode just it's 4096 colors (6bpp) or 262144 colors (8bpp) [11:23:22] <wbs> whichever way you do it, remember that you can't just stash some generic struct into the extradata field, the format should be well-specified (even if the extradata format is different for each codec) [11:23:50] <BastyCDGS> so put the declaration in iff.h so it's available public [11:24:29] <wbs> no, that wouldn't be enough, you can't memcpy a struct like that generically [11:24:50] <wbs> what you put in AVCodecContext->extradata is the "official wire format" of that data, like what's in AVPacket->data [11:25:01] <wbs> and should be binary compatible between different builds/architectures etc [11:25:47] <wbs> if I for example demux the data somewhere, store the extradata and packet data somewhere, and then want to decode somewhere else, on a different machine [11:27:01] <Tjoppen> BastyCDGS: while I'm not sure what ECB, wouldn't it and HAM count as separate codecs? [11:27:11] <Tjoppen> *ECB is [11:27:47] <BastyCDGS> ECB is like normal palette just that the upper half of colors is 50% brightness [11:27:57] <BastyCDGS> of the lower half [11:28:29] <Tjoppen> so implement that as a normal raw 8-bit video output, and HAM as an intra-only codec ("ham") [11:28:45] <BastyCDGS> so let's say a 6 planar colormap (64 colors) in ECB mode contains 5 plane color values (0-31 color indices) and you have to initialize colors 32-63 with 50% brightness of 0-31 [11:29:09] <Tjoppen> yes, that shouldn't be too much of a problem. just look at some palette format demuxer, such as FLIC [11:29:33] <Tjoppen> err.. except FLIC is compressed [11:30:22] <Tjoppen> anyway, as long as the demuxer can set the palette you should be OK [11:32:23] <BastyCDGS> the thing is that the current implementation just puts the raw CMAP in the extradata and does decoding the CMAP on the decoder side [11:32:41] <BastyCDGS> is it appreciated to change that such the demuxer decodes the CMAP and the decoder simply applies it? [11:32:51] <BastyCDGS> then I wouldn't need extraflags at all [11:32:57] <Tjoppen> have both demuxer and decoder share the CMAP decoding code then [11:33:28] <Tjoppen> that way you don't need to put that special struct in extradata, but the CMAP decode function can output it [11:37:10] <Yuvi> how does ffmpeg read VLCs longer than 16 bits? [11:37:52] <mru> what makes you thing 16 bits is a special length? [11:38:52] <Yuvi> oh, I guess it's just vp3 that uses uint16_t [11:44:38] <Yuvi> okay, new question: is it possible to read 32 bits without using tables of size 2^11? [11:45:09] <Yuvi> and if you only have 32 symbols, is it even possible to have huffman codes of 32 bits? [11:45:59] <mru> depends on how you construct the codes [11:46:11] <mru> unless you're a total idiot, I doubt you'll get 32-bit codes [11:46:29] <Yuvi> theora allows it :/ [11:46:35] <Tjoppen> 31 at most, and even that is not very likely [11:46:40] <mru> well, they _are_ total idiots [11:46:45] <pross-au> that would be a crap tree [11:47:18] <mru> GET_VLC allows only 3 levels of tables [11:47:34] <mru> so you'd have to have 11 bits per level, yes [11:48:36] <mru> I guess the worst case is codes like this: [11:48:37] <mru> 0 [11:48:38] <mru> 01 [11:48:44] <mru> err, 10 [11:48:46] <mru> 110 [11:48:47] <mru> 1110 [11:48:47] <mru> etc [11:49:44] <Tjoppen> ah, right. wrong of me then. doi! [11:50:18] <mru> doi, is that french for duh? [11:50:22] <pross-au> mru *BUT* [11:50:34] <pross-au> such a table would never happen [11:50:43] <pross-au> unless it was generated by a moron [11:50:47] <mru> that's what I said [11:51:08] <mru> the question is, can we expect morons? [11:51:17] <mru> and with theora, the answer is yes [11:51:17] <pross-au> Sounds like rice coding [11:51:21] <pross-au> With VLCs [11:51:36] <Yuvi> given that it took this long to find an issue with using uint16_t, maybe not [11:53:13] <pross-au> Just wait till those same people get their hands on VP8 [11:53:13] <Yuvi> lemme see if 10 vs. 11 makes a significant difference on my machines [11:53:27] <mru> double table size [11:53:51] <mru> otoh twice as many codes will fit in the first level [11:54:09] <mru> make a huge difference in aac [11:55:09] <av500> Tjoppen: it will matter when trancoding [11:56:09] <Tjoppen> as long as the encoder supports it, no problem I guess. otherwise you can't help resampling from 11024 to 11025 [11:56:28] <Tjoppen> which'd depend on whether supported_samplerates is NULL or not [11:56:52] <Tjoppen> or if the encoder has explicit support for such a samplerate [11:57:07] <mru> or you pretend they're the same and adjust the video frame rate ever so slightly [11:57:21] <av500> I think I just declared 11024=11025 in my app :) [11:59:14] <BastyCDGS> question, is such code "legal"? I use this for ECB [11:59:17] <BastyCDGS> pal[i] = 0xFF000000 | AV_RB24( avctx->extradata + i*3 ); [11:59:17] <BastyCDGS> pal[j] = 0xFF000000 | (AV_RB24( avctx->extradata + i*3 ) >> 1); [11:59:47] <BastyCDGS> the >> 1 in the pal[j] line shall make the 50% brightness [12:00:02] <wbs> no, that won't work [12:00:18] <mru> there's a nice macro for that somewhere [12:00:19] <wbs> you'll shift in the lowest bits from one color into the highest bits of next [12:00:20] <mru> hold on [12:00:48] <BastyCDGS> wbs, argl yeah you're right... [12:00:57] <mru> dsputil.h [12:01:08] <mru> rnd_avg32() and no_rnd_avg32 [12:01:26] <mru> you could simplify one of those for 0 on one side [12:01:31] <mru> if gcc doesn't do it for you [12:01:38] <janneg> av500: max error is probably .16s since cameras are usually limited to 29:59 min of video [12:01:51] <av500> janneg: thats why I did not care :) [12:02:01] <janneg> to avoid higher duties on camcorders [12:02:18] <mru> 11024 and 11025 are close enough that nobody can tell the difference [12:02:50] <av500> sure [12:02:57] <mru> I'll notice 1% pitch change [12:03:13] <mru> even if not listening back to back [12:03:27] <av500> change yes, but absolute? [12:04:17] <mru> if I listen to a song a few times, then hear it again much later played 1% faster I can notice [12:04:36] <mru> I wouldn't notice notes being off just by hearing it once [12:04:53] <mru> some people do [12:05:00] <mru> musicians typically [12:05:06] <av500> most ppl dont notice the 4% change for 24->25fps [12:05:17] <mru> that's because it's not there [12:05:33] <mru> they do a pitch-preserving compression [12:05:39] <av500> they downpitch? [12:05:41] <av500> ah [12:05:43] <janneg> av500: I would expect the audio to be resampled [12:05:55] <mru> a 4% increase in pitch sounds like chipmunks [12:06:02] <av500> janneg: resampling does not help [12:06:26] <BastyCDGS> calling rnd_avg32(0xFFFFFF,0) will result in 0x808080? [12:06:31] <merbzt> 11024/11025 ~ 0.01 % [12:06:32] <av500> whatever it is they do make the stupid movie end faster :) [12:06:56] <mru> mythtv has a nice 1.5x mode [12:06:56] <av500> merbzt: I was mentioning that as a real world example of why not to stritlcy match samplerate in the above proposal [12:07:01] <mru> as does ps3 [12:07:16] <av500> not because ppl can hear the diff [12:08:19] <janneg> yes, I ment pitch preserving tempo changes [12:08:23] <av500> BastyCDGS: no, 0x7F,5 .) [12:08:39] <mru> av500: that's 0x7f.8 [12:08:40] <janneg> mythtv uses soundtouch [12:09:05] <BastyCDGS> av500 it takes uint32_t as in/out ;) [12:09:06] <av500> mru: I am free to define my own number format :P [12:09:23] <mru> BastyCDGS: this is #ffmpeg-devel [12:09:29] <mru> anything goes [12:09:55] <BastyCDGS> just want to be sure [12:14:07] <BastyCDGS> const uint32_t col_val = AV_RB24( avctx->extradata + i*3); [12:14:07] <BastyCDGS> pal[i] = 0xFF000000 | col_val; [12:14:07] <BastyCDGS> pal[j] = 0xFF000000 | (col_val & 0xFEFEFE) >> 1; [12:14:13] <BastyCDGS> I solved it that way, should do it ;) [12:15:32] <BastyCDGS> this, of course, rounds downwards, but the original ECB code from IFF ANIM does it that way, too. [12:17:05] <BastyCDGS> I seen my mistake, the original code was doing this per-byte basis thus it was legal to do / 2 [12:17:31] <KotH> we not only design our own OS to for standard compliance, but now also our own number format or what? [12:23:55] <Tjoppen> neat trick [12:30:04] <BastyCDGS> question, pixfmt.h is only for pixel format ffmpeg outputs (thinking about adding HAM6 and HAM8 there) [12:30:10] <BastyCDGS> ? [12:34:23] <mru> what are those? [12:35:37] <BastyCDGS> they allow 4096 and 262144 colors with a 6-bit / 8-bit palette only [12:35:45] <BastyCDGS> and are natively used by amiga hW [12:36:02] <BastyCDGS> to be displayed at once [12:36:47] <BastyCDGS> consider them some sort of pseudo-true-color [12:37:00] <mru> what do the pixels look like? [12:37:29] <BastyCDGS> http://en.wikipedia.org/wiki/Hold-And-Modify [12:37:54] <av500> mru: they look like this: . [12:38:20] <mru> that's two pixels in my font [12:38:39] <av500> it was not to scale [12:40:01] <mru> oh [12:42:28] <Tjoppen> having HAM be a pixel format sounds wrong [12:42:39] <Tjoppen> in that case ADPCM could be a sample format [12:43:33] <mru> yes [12:43:36] <ohsix> since it doesn't have to be strobed out on real hardware wouldn't it make sense to decode it to a 4096 or 262k color format? [12:43:53] <mru> or to plain old rgb24 [12:44:07] <mru> or 32 as the case may be [12:44:12] <BastyCDGS> there's a HAM6/8 decoder to rgb24 in iffanim.c ;) [12:44:27] <BastyCDGS> so it's probably better to use that, but wanted to discuss this out first [12:45:59] <BastyCDGS> when I've finished that and everything else is fine, then IFF-ANIM should display the first picture correct ;) [12:46:38] <BastyCDGS> then I have to do the eric graham decoder (it's the most widespread in IFF-ANIM) and the iff anim demuxer should work (except sound) [12:49:39] <Tjoppen> speaking of old formats, perhaps I should commit my "terror from the deep" fix for the flic demuxer. mike OK:ed it and has samples, so I assume he'll take it from here [12:49:52] <jai> merbzt: ping [12:49:53] <Tjoppen> if he wants any tests that is [12:53:21] <pross-au> HAM flickers though [12:53:49] <pross-au> u dont get that with current pixfmt [13:01:42] <CIA-7> ffmpeg: vitor * r22929 /trunk/libavformat/mtv.c: Fix MTV decoding on big-endian systems [13:06:17] <CIA-7> ffmpeg: vitor * r22930 /trunk/libavcodec/amrnbdec.c: 10l: do not try to unpack DTX frames in AMR-NB decoder [13:12:14] <Yuvi> ok, 11 vs. 10 is enough of a wash that I can't justify not supporting stupid huff trees [13:15:29] <BastyCDGS> is there a more recommended way than doing this in avcodec.h to support all these stuff? [13:15:31] <BastyCDGS> CODEC_ID_IFF_ANIM0, [13:15:31] <BastyCDGS> CODEC_ID_IFF_ANIM0_HAM6, [13:15:31] <BastyCDGS> CODEC_ID_IFF_ANIM0_HAM8, [13:15:39] <BastyCDGS> CODEC_ID_IFF_ANIM1, [13:15:39] <BastyCDGS> CODEC_ID_IFF_ANIM1_HAM6, [13:15:39] <BastyCDGS> CODEC_ID_IFF_ANIM1_HAM8, [13:15:42] <BastyCDGS> ... [13:16:11] <Yuvi> can you determine the version / whatever based on anything other than the codec id? [13:16:31] <Yuvi> or stuff it in the extradata if it's only in one container [13:16:41] <BastyCDGS> would be possible, yes... [13:16:56] <wbs> if you unpack the color map into the palette in the demuxer, is there any need to differentiate between them in the decoder at all? [13:17:26] <BastyCDGS> HAM also changes the image format itself [13:17:41] <BastyCDGS> it's not only the palette [13:17:56] <wbs> ok [13:18:31] <BastyCDGS> so the best way is just have one CODEC_ID_IFF_ANIM but also for HAM6/8? [13:19:11] <mru> if they are just variants of the same codec, they should probably use the same codec id [13:19:25] <mru> it's like we don't use different IDs for PNG depending on the compression type or pixel format [13:19:41] <av500> CODEC_ID_PNG_LOLCATZ [13:19:53] <CIA-7> ffmpeg: conrad * r22931 /trunk/libavcodec/vp3.c: theora: coeff huffman codes are allowed to be up to 32 bits long (for 32 tokens) [13:20:38] <BastyCDGS> i ask because the original IFF code also had two different decoders for byterun and raw image data for ILBM [13:23:22] <av500> __attribute__((optimize("no-omit-frame-pointer"))); ??? [13:23:32] <mru> where? [13:24:04] <av500> speex resampler [13:24:11] <mru> go figure [13:24:41] <av500> I have to mention we had to remove that? [13:25:31] <peloverde> __attribute__((optimize(0))) is the only way I can manage to debug ffmpeg [13:25:58] <merbzt> peloverde: why ? [13:26:03] <ohsix> theres a configure parameter [13:26:23] <peloverde> because builds with -O0 fail and even -O1 seems to fuck up gdb [13:26:35] <peloverde> which parameter? [13:26:37] <ohsix> just setting CFLAGS? [13:27:54] <merbzt> peloverde: do you add -g3 ? [13:28:17] <peloverde> I don't add anything [13:28:20] <BBB___> merbzt: can you ask andreas to apply as google mentor? [13:28:24] <BBB___> so I can allocate him [13:28:27] <ohsix> --disable-optimizations disable compiler optimizations [13:28:51] <ohsix> theres a grip of them [13:28:54] <merbzt> BBB: you're soooooooo slow [13:28:59] <BBB> huh? [13:29:02] <BBB> I guess [13:29:05] <merbzt> F5 [13:29:15] <BBB> I checked the google list 5 seconds ago [13:29:31] <BBB> mentor: stefano [13:29:33] <BBB> that's wrong [13:29:36] <merbzt> mr oman is there since yesterday [13:29:44] <merbzt> ahh ok, I get it [13:29:53] <merbzt> he prefered to be co-mentor [13:30:03] <merbzt> leave it as it is [13:30:05] <BastyCDGS> BBB, you speaking of my mentor, I guess [13:30:16] <merbzt> BastyCDGS: -> andoma [13:30:29] <BBB> brb [13:30:30] <BBB> lab meet [13:31:01] <BastyCDGS> btw, stefano told me yesterday evening he'ld like my second mentor, too. [13:31:10] <merbzt> peloverde: --disable-optimizations --enable-debug=3 works fine for me when debugging with kdevelop and ddd [13:31:48] <jai> --disable-asm --disable-optimizations too [13:32:23] <ohsix> it only took --d-o to reify gdb the few times i've needed to [13:32:58] <peloverde> you start throwing disable-asm around and all the sudden you are using different mdct scaling and whatnot [13:33:12] <merbzt> peloverde: true :) [13:33:53] <Yuvi> ugh, I managed to miss a cosmetic before pushing that [13:35:13] <peloverde> though --disable-optimizations does seem to build ok [13:36:17] <ohsix> \m/ [13:36:19] <merbzt> add -g3 for source level debuggability [13:45:15] <kierank> is there any way in gdb (or ddd) to continue running until a certain address? [13:45:29] <Yuvi> break * address ? [13:45:30] <kierank> (a breakpoint won't work) [13:46:09] <kierank> that won't work in this case because of the mmap loaded binary [13:46:32] <ohsix> force the full load? LD_SOMETHING :> [13:46:35] <Yuvi> now I'm curious why not? [13:46:51] <Yuvi> how does mmap break that? [13:46:54] <kierank> hmmm I wonder if it will work when you're actually running in the code segment [13:47:48] <ohsix> maybe an old gdb that wont reapply when modules are loaded [13:48:25] <ohsix> LD_BIND_NOW btw; wont work for dlopen stuff thats to come in the future though :9 [13:48:38] <kierank> seems to work when you're actually running in the code segment [13:49:54] <kierank> hmmm later on it fails [14:08:54] <BastyCDGS> uhh something crazy happened [14:09:15] <BastyCDGS> wanted to configure but kate did change to subdir of libavcodec [14:09:35] <BastyCDGS> since I do this normally from a build dir with ../configure it created makefile files there [14:09:44] <BastyCDGS> which broke everything totally [14:09:58] <BastyCDGS> had to do rm -rf and svn up [14:11:15] <BastyCDGS> when using kate with the embedded console it does automatically a cd into the dir where the file you're editing is [14:11:29] <BastyCDGS> I didn't notice that and to the configure was exec'd in wrong dir [14:13:00] <KotH> note: there is nothing that beats a bunch of terms and vim [14:16:02] <BastyCDGS> joe is a good editor also [14:17:28] <jai> sam and acme too ;) [14:25:56] <BastyCDGS> it works!!!!!! [14:26:01] <BastyCDGS> window opens with iff anim [14:26:11] <BastyCDGS> although shows some garbarge right now [14:28:43] <BastyCDGS> for testing I hardcoded it to the IFF-ILBM raw decoder [14:29:02] <BastyCDGS> I think I just have to implement the correct decoder ;) [14:30:03] <BastyCDGS> easiest way would be implement it with: [14:30:26] <BastyCDGS> a different decoder each compression format supported [14:30:32] <BastyCDGS> like the original IFF code does also [14:30:41] <BastyCDGS> then we have ANIM0-8/ANIM-K [14:30:59] <BastyCDGS> can i do this way right now just for getting it to work? [14:49:27] <merbzt> sure, get it working first [14:49:43] <merbzt> shouldn't be to hard to change if it's better another way [15:26:22] <BastyCDGS> wb BBB [15:26:49] <BastyCDGS> did you read that IFF-ANIM now opens window an shows first image (though garbarged) [15:26:56] <BastyCDGS> working on the decoder stuff [15:27:48] <BBB> no, but that's good news [15:27:56] <BBB> andoma: can you subscribe to google as a mentor for soc? [15:29:57] <BastyCDGS> just to reminder, deadline is 1700 UTC [15:30:13] <BBB> yes [15:30:15] <BastyCDGS> for scoring students [15:30:22] <BBB> merbzt: what do we do with michael chinen? [15:30:32] <BBB> BastyCDGS: you're fine, but keep working on the qualification task [15:30:34] <BastyCDGS> btw, should I provide a patch now for the current state [15:30:37] <BBB> yes [15:30:40] <BastyCDGS> ok [15:30:47] <BastyCDGS> just compiling if it still works ;) [15:30:55] <BastyCDGS> if that's ok I will commit patch [15:31:31] <BastyCDGS> btw, yesterday when I finished talking with saste something funny happened [15:31:41] <BastyCDGS> before I went to bed I did an aptitude dist-upgrade [15:31:47] <BastyCDGS> and what I see, ffmpeg :D [15:31:52] <BastyCDGS> only ffmpeg :D [15:32:13] <BastyCDGS> but it's still a 2007 cvs version [15:34:46] <BastyCDGS> compile & ffplay successful, that is with the garbled image ;) [15:34:51] <BastyCDGS> so I will prepare patch [15:34:56] <andoma> BBB: i believe i've already did that? [15:35:04] <BBB> what did you do? [15:35:29] <BBB> ah there, you are there now [15:35:32] <BBB> ok, you're assigned [15:35:53] <BBB> thanks [15:36:01] <BBB> merbzt: please advise on michael chinen again :) [15:36:30] <andoma> BBB: ok :) [15:36:35] <BastyCDGS> me? added EHB support etc. [15:37:04] <BBB> BastyCDGS: no, andoma :) [15:42:48] <BastyCDGS> patch commited to ml [15:42:57] <BastyCDGS> could you review it, BBB? [16:08:19] <DonDiego> BastyCDGS: you don't "commit" a patch, you "submit" it [16:08:39] <DonDiego> "commit" is what is done to your patch subsequently if it is accepted [16:09:00] <av500> DonDiego: you throw it into the cold waters of the ML [16:10:03] <BastyCDGS> well, dict.leo.org says (english => german) both words are synonymous [16:10:07] <BastyCDGS> übergeben, überreichen ;) [16:10:57] <BastyCDGS> but if you like I will write submit instead of commit in the future ;) [16:12:23] <BastyCDGS> it's like sign in and login [16:14:33] <DonDiego> no, it's not synonymous [16:14:57] <DonDiego> neither are übergeben and überreichen .. [16:15:23] <DonDiego> "submit" means (roughly) giving something to somebody [16:15:34] <av500> sich übergeben und sich überreichen are not the same [16:15:46] <DonDiego> "commit" means (roughly) that there is a commitment [16:15:49] <BastyCDGS> av: lol [16:16:06] <DonDiego> you can commit yourself to a task [16:16:34] <DonDiego> you cannot submit yourself to a task [16:16:35] <iamlindoro> BastyCDGS: Submitting something implies it is for the other party to approve. Commit means you make the change. (at least, in this context) [16:16:48] <BastyCDGS> ahh ok... [16:17:14] <DonDiego> BastyCDGS: i'm just teaching you the standard vocabulary so that people don't have trouble understanding you.. [16:17:38] <BastyCDGS> thank you for this, I'll write submit in the future ;) [16:17:42] <DonDiego> :) [16:17:58] <BBB> BastyCDGS: will review, give me a bit [16:18:00] <BBB> busy with work [16:18:01] <BBB> :) [16:18:27] <BBB> ham6/8... [16:18:28] <BBB> hmm... [16:18:32] <BBB> I remember that from lasst year's soc [16:19:01] <BastyCDGS> most of the movies in the anim sample pack won't work without HAM support [16:19:16] <BastyCDGS> just try ffplay out with the patch (it bumps an error message if it's HAM6/8) [16:20:14] <BastyCDGS> if you want intend to change my score in gsoc after reviewing it, you should do this within next 40 minutes ;) [16:20:36] <BastyCDGS> the iff anim sample cpp source has a HAM6/8 to 24bpp converter [16:23:32] <BastyCDGS> it's just that I still have to figure out what's the best way to integrate HAM in ffmpeg [16:25:21] <BBB> uhm, I'm admin for soc, I can see which students will be accepted :) [16:25:35] <av500> BBB: you got the power [16:25:39] <BBB> \o/ [16:26:03] <BBB> BastyCDGS: score is for ranking, we don't use scores, we use mentor assignment instead [16:26:10] <BBB> you have a mentor assigned, so you're fine [16:26:35] <BBB> BastyCDGS: try to interact with andoma a bit so you guys get to know each other, he'll help mentoring you, he knows mod better than me or saste [16:26:39] <BBB> but we'll all help you [16:27:14] <BastyCDGS> I sometimes ask if I need help for mod directly at all, don't forget that this is absolutely my domain, I'll more likely need help for ffmpeg related stuff [16:27:28] <BBB> right, so we can help with all of that :) [16:27:38] <BastyCDGS> as completely opposed to video stuff, this is almost completely new for me [16:27:40] <BastyCDGS> ;) [16:27:52] <BastyCDGS> switching from iff-anim to mod will be like a fish returning to water ;) [16:28:04] <BastyCDGS> at least for me ;) [16:29:09] <BastyCDGS> I'm not experienced just with mod decoding also with encoding including a complete own format [16:29:36] <BastyCDGS> so maybe ffmpeg will then able to convert xm to mod, it to s3m, s3m to tcm, whatever [16:30:37] <BastyCDGS> bbb, one question though, you said you don't use scoring but mentoring instead... [16:30:56] <BastyCDGS> stefano yesterday said that you got 10 slots allocated by google and if it's more than 10 the best ranked students will be accepted [16:31:13] <BastyCDGS> maybe you could clarify on that, it sounds a little bit contraversal... [16:32:14] <BBB> BastyCDGS: trust me, you're fine [16:32:55] <BastyCDGS> so I can consider me accepted? [16:33:12] <BastyCDGS> yippppppppppppppieeeeeeeeee [16:33:21] * BastyCDGS hands out a bottle of beer to everyone [16:34:09] <BastyCDGS> a lot of you have recommended me to switch to git [16:34:21] <mru> oh yes [16:34:25] <BastyCDGS> any good advices to do it best? [16:34:36] <mru> read a primer and dive in [16:34:38] <BastyCDGS> i.e. learn it the fastest way [16:34:48] <BastyCDGS> so we won't lose time on that [16:35:01] <mru> you'll save many days of frustration [16:35:36] <BastyCDGS> apt-installing git right now ;) [16:35:53] <BastyCDGS> git 4.3.20 is fine? [16:35:58] <mru> uh? [16:35:58] <bilboed> git-core [16:36:09] <mru> 1.7.0.x is current [16:36:18] <bilboed> yet-another fine example of why I hate debian renaming packages :) [16:36:45] <BastyCDGS> git-core installing now...1.5.4 [16:36:45] <wbs> well, they had some other package named git earlier [16:36:49] <kierank> http://spheredev.org/wiki/Git_for_the_lazy [16:37:07] <wbs> but in debian unstable, that one is removed and it's available as simply "git" [16:37:37] <mru> yeah, when you have one obscure and one wildly popular thing with the same name, which do you rename? [16:37:56] <bilboed> use prefixes like gentoo [16:37:57] * bilboed runs :) [16:38:06] <mru> that's one good way [16:38:07] <BastyCDGS> kierank: thanx looks very good [16:38:55] <BastyCDGS> shall I remove the .svn files (i.e. do they harm) before doing a first git checkout? [16:39:29] <mru> you can't do a git checkout on top of existing files [16:39:31] <mru> it won't let you [16:40:03] <bilboed> BastyCDGS, if you have no local changes, just do a fresh clone [16:40:23] <BastyCDGS> ehm I have lots of local changes ;) [16:40:30] <BastyCDGS> the whole IFF-ANIM stuff e.g. [16:40:43] <BastyCDGS> so I better backup my files [16:40:49] <bilboed> make diff into a patch, you'll be able to put it back in your git checkout later [16:41:03] <wbs> do a separate git clone, and then apply the changes in small chunks in yout git clone [16:41:12] <wbs> (preferrably in a separate branch there) [16:41:33] <wbs> applying the whole patch from svn diff and adding one part at a time with git add -p may be an option, too [16:44:43] <mru> or use git gui [16:44:48] <mru> it's quite nice actually [16:45:06] <BastyCDGS> there's a package git-svn I see... [16:45:25] <BastyCDGS> and even git-buildpackage looks great!!! [16:45:38] <BastyCDGS> so I can directly build debian packages with a git repo? [16:45:51] <bilboed> BastyCDGS, there's mixed feeling about git-svn [16:46:04] <BastyCDGS> what it actually does? [16:46:10] <BastyCDGS> migrate a svn repository to git? [16:46:19] <mru> the libswscale situation is annoying [16:46:39] <mru> other than that it's fine [16:46:47] <bilboed> mru, I'd say submodules... but it doesn't come without it's share of pain [16:46:55] <bilboed> s/it's/its/ [16:46:59] <mru> submodules don't do the right thing here [16:47:01] <peloverde_> you can't dcommit from git.ffmpeg.org [16:47:11] <peloverde_> but can from git.mansr.com [16:47:41] <bilboed> mru, is that the only thing blocking ffmpeg from switching to git as main repo ? [16:47:53] <mru> that's not blocking it at all [16:47:58] <mru> michael and diego are [16:48:27] <elenril> michael is against? [16:48:39] <mru> more or less [16:48:44] <bilboed> mru, lol :) so like every project switching to git... it's about politics [16:48:44] <mru> that's my impression at least [16:48:45] <BastyCDGS> btw, svn is sometimes a pain in eclipse...esp. within windows [16:48:56] <BastyCDGS> it randomly says locked even if you didn't a lock etc. [16:49:03] <elenril> why not vote about it? [16:49:11] <bilboed> BastyCDGS, lock ? there's no lock in git [16:49:27] <bilboed> oh, svn /me facepalms [16:49:35] <BastyCDGS> so git is more like a transactional db? [16:49:39] <mru> elenril: we don't vote here [16:50:39] <elenril> i remember a vote about ffmpeg foundation =p [16:50:50] <mru> and look what a mess that was [16:50:55] <peloverde> the foundation is different [16:51:17] <BastyCDGS> anyone has experience with this? [16:51:18] <BastyCDGS> http://www.eclipse.org/proposals/egit/ [16:51:33] * mru recommends not touching eclipse [16:51:34] <kierank> hehe eclipse [16:51:34] <bilboed> BastyCDGS, if you *really* want to understand git, read this : http://ftp.newartisans.com/pub/git.from.bottom.up.pdf [16:51:37] <BastyCDGS> (no I won't use eclipse with ffmpeg but I have some eclipse projects using svn) [16:52:02] <bilboed> BastyCDGS, once you've groked that doc... everything else in git will be crystal clear [16:52:11] <BastyCDGS> and if git is so much better I would transfer my other stuff from svn to git too [16:52:32] <BastyCDGS> thanks bilboed, just wgot ist ;) [16:52:39] <BastyCDGS> it [16:52:54] <bilboed> once you get used to it... you will never want to go back [16:55:15] <BastyCDGS> mru, you're right about not recommending eclipse, it's really bloat and memory wasting and sloooooow [16:55:18] <BastyCDGS> java shice [16:55:33] <BastyCDGS> but when I start using it long time ago I didn't knew about that [16:56:12] <mru> always look for an escape route _before_ you start using something [16:56:29] <BastyCDGS> I would have quit that if I wouldn't do some project with GUIs which force be to use eclipse since they use svn with eclipse project [16:56:40] <elenril> mru: still wouldn't it be better if somebody raised the issue openly rather than all these little hidden flamewars on cvslog? [16:57:11] <BastyCDGS> GUIs oops? [16:57:11] <BastyCDGS> i wanted to write guys [16:57:38] <mru> choose your friends carefully :-) [16:58:07] <BastyCDGS> I do now, proof is that I decided for ffmpeg now ;) [16:58:43] <BastyCDGS> at university we're forced to use eclipse also [16:59:03] <BastyCDGS> if you ask me teaching IT in german is really bad [16:59:03] <mru> choose universities carefully too [16:59:09] <mru> it's bad everywhere [16:59:18] <mru> I know, I used to do it [16:59:22] <BastyCDGS> they even teach you to write code this: [16:59:26] <BastyCDGS> int zaehler = 3; [16:59:30] <BastyCDGS> i.e. german variable names etc. [16:59:32] <BastyCDGS> argggggggh [16:59:38] <BastyCDGS> even german comments [16:59:50] <mru> I've had to debug customer code with comments in chinese [16:59:51] <kierank> presumably an issue of national job security [17:00:06] <mru> it didn't matter of course, since the comments were all wrong anyway [17:00:32] <BastyCDGS> which really break when a linux student developer opened his project in eclipse at a reading [17:00:39] <BastyCDGS> UTF-8 <=> cp1252 ;) [17:00:51] <BastyCDGS> with plain english you just have us-ascii no problem [17:01:11] <mru> they used non-7-bit characters in variable names? [17:01:22] <av500> zähler [17:01:25] <BastyCDGS> mostly comments [17:01:34] <av500> / blöde scheisse [17:01:36] <mru> java allows it, I know [17:01:37] <BastyCDGS> remember we do java there [17:01:41] <mru> doesn't mean you should do it [17:01:52] <mru> just like java existing doesn't mean you should use it [17:01:58] <kierank> oh lawd [17:01:58] <BastyCDGS> java can't even do unsigned what holy shit is this? [17:02:08] <av500> mru: but it makes your nice phone run nice [17:02:18] <av500> BastyCDGS: it is "holy" [17:02:19] <kierank> av500: and slow as hell [17:02:27] <av500> kierank: not really [17:02:33] <BastyCDGS> oh right [17:02:38] <mru> java has one unsigned type: char [17:02:43] <mru> shame it's only 16 bits [17:03:02] <BastyCDGS> I mean unsigned like in c so you can decide for each primitive [17:03:02] <av500> shame it is not 8bit as well :) [17:03:20] <mru> for 16-bit numbers you can choose [17:03:25] <mru> short is int16_t [17:03:27] <mru> char is uint16_t [17:03:28] <BBB> BastyCDGS: you're accepted, but we want you to finish the qual task [17:03:33] <mru> so java is a 16-bit language [17:03:38] <BBB> BastyCDGS: otherwise we'll still throw you out of the list ;) [17:03:45] <BastyCDGS> as already said I want to finish the qualification task anyway ;) [17:03:49] <BBB> good :) [17:03:55] <BBB> and yes, do git [17:04:03] <BBB> and vote for the git switch guys, let's do it [17:04:06] <BastyCDGS> I also said to do the other quali task we're discussed at first [17:04:09] <BastyCDGS> resampler stuff [17:04:12] <BBB> all this "let's wait and see" is just not helping us move forward [17:04:16] <BastyCDGS> making at SSE/SSE2 etc. ready [17:04:24] <BBB> that's supercool [17:04:43] <mru> I won't switch the repos to git until michael and diego have used git-svn for a bit [17:05:06] <BBB> no, no [17:05:08] <BBB> git-svn sucks [17:05:14] <mru> it's fine [17:05:23] <BBB> it sucks [17:05:24] <bilboed> git-svn sucks [17:05:25] <BBB> I hated it [17:05:26] <BastyCDGS> today is unfortunately my last vacation day, tomorrow work begins again [17:05:31] <mru> then you did it wrong [17:05:43] <BastyCDGS> but we don't have too much to do [17:05:51] <bilboed> it's like winning a ferrari but living in a country with no roads [17:06:02] <BastyCDGS> so I guess I can continue almost as until now [17:06:33] <mru> more like winning a ferrari but being restricted to country lanes [17:06:36] <mru> but at least you have a car [17:06:44] <mru> before that you had to walk everywhere [17:06:46] <mru> backwards [17:06:50] <BBB> mru: don't bring up git-svn, it sucks and is incompetent [17:06:52] <BBB> just do git [17:06:58] <BBB> let them (and me) suffer [17:07:07] <BBB> we all know it's better [17:07:07] <mru> what exactly sucks about it? [17:07:14] <BBB> it can't fix commit msgs [17:07:20] <mru> neither can git [17:07:31] <bilboed> you can locally [17:07:33] <mru> sure [17:07:36] <BBB> right, you can locally [17:07:43] <BBB> but with git-svn, that breaks completely [17:07:47] <mru> you can do that with git-svn too before you dcommit [17:07:48] <BBB> and then your repo is out of sync [17:07:50] <BBB> and you're fucked [17:07:59] <BBB> no you can't, I tried and it fucked up [17:08:06] <mru> no, _you_ fucked up [17:08:08] <BBB> that's my first and last try of using git-svn [17:08:12] <BastyCDGS> lol [17:08:12] <BBB> I fucked up indeed [17:08:18] <BBB> and my repo stopped working [17:08:19] <wbs> you can fuck up just as much with normal git if you don't know what you're doing :-) [17:08:22] <BBB> that's unacceptable [17:08:22] <mru> you can do whatever you want to commits you haven't dcommitted yet [17:08:37] <BBB> anyway, please gitify us [17:09:01] <BBB> I'll commit my qcelp postfilter in a sec \o/ [17:09:05] <mru> not without michael's and diego's explicit consent [17:09:12] <mru> to git, not postfilter [17:09:53] <av500> a large # of ppl asking for git will not convince them? [17:09:56] <BastyCDGS> btw, bbb what's with my patch i submitted [17:09:57] <BastyCDGS> ? [17:10:14] <BBB> mru: got it ;) [17:12:29] <BastyCDGS> discussing java ;) what do you guys think about C++? [17:13:10] <mru> c++ is a combination of all things bad and evil [17:13:43] <BastyCDGS> I don't like object orientation, too... [17:14:20] <BastyCDGS> but at least it's still optional in c++ [17:14:21] <BBB> BastyCDGS: I'll review it [17:14:31] <BBB> BastyCDGS: but I'm doing other stuff first (my own code ;) ) [17:14:45] <mru> sure, most of the nasty stuff in c++ is optional [17:14:59] <BBB> BastyCDGS: C is good, it's fast, easy to compile and going from asm<->c is easy, it's easy to write optimal code and it's hard to fuck up [17:14:59] <mru> but when you take it away you're left with a somewhat crippled C [17:15:04] <BBB> with c++, it's too easy to fuck up [17:15:05] <mru> better to use C directly [17:15:15] <bilboed> BastyCDGS, c++ without OOP ... is C (give or take) [17:15:36] <mru> c++ without the "features" is less than C [17:15:56] <bilboed> haven't done enough (thank god) c++ to realize [17:15:59] <BastyCDGS> templates itself aren't really OOP or force you to use OOP so it's not 100% C ;) [17:16:16] <BastyCDGS> but I don't like templates either [17:16:35] <BastyCDGS> the only exception where C++ is pretty well, is using wxWidgets [17:16:41] <mru> any language where error messages span multiple pages is broken [17:16:44] <BastyCDGS> but they use only the most basic stuff of OOP [17:17:55] <BastyCDGS> I wonder why all these OOP guys think that it provides less error-prone code [17:18:14] <bilboed> OOP doesn't imply that [17:18:15] <BastyCDGS> when I compare typical OOP stuff it has more errors than C/Asm [17:18:20] <peloverde> http://imgur.com/DanrT [17:18:27] <bilboed> don't confuse OOP and C++ [17:18:52] <elenril> ffmpeg is oop! [17:19:04] <BastyCDGS> that's why I wrote typical OOP ;) [17:19:29] <BastyCDGS> ffmpeg oop and TuComposer oop isn't typical it's perfect [17:20:45] <BastyCDGS> :D [17:22:24] <BastyCDGS> I think the reason why C/Asm stuff is in general less error-phone is that it just requires more knowledge to get started at all with it [17:23:14] <av500> BastyCDGS: I fail to see the connection between c vs v++ and "error prone" [17:23:49] <BastyCDGS> in C you know you have to manage all your resources (alloc/free) [17:24:07] <BastyCDGS> this is not implicit in java/C++ (some guys assume e.g. the destructor just doing all stuff etc.) [17:24:49] <BastyCDGS> the other stuff is that C++ isn't ABI compatible between diff. C++ compilers [17:25:04] <BastyCDGS> (try to link a MSVC class with a gcc class) [17:25:44] <BastyCDGS> or even try to link a g++ 3.x class with a g++ 4.x one [17:26:06] <mru> or compile the same source with different compilers [17:26:16] <mru> that usually fails too [17:26:39] <BastyCDGS> unless you have more #ifdef's than actual source :D [17:26:46] <mru> that's flash [17:26:50] <mru> and it still doesn't work [17:27:08] <mru> parts of it actually do have more ifdefs than actual code [17:27:27] <kierank> how do you know? [17:27:27] <mru> it was something like 15% ifdefs overall [17:27:31] <mru> I counted them [17:27:43] <mru> flashlite, not the full version [17:27:51] <mru> I'm told the full version is worse [17:30:00] <BastyCDGS> which flash stuff? [17:30:12] <BastyCDGS> you don't really mean that adobe stuff, right? [17:30:16] <av500> yes [17:30:17] <mru> yes, adobe [17:30:40] <BastyCDGS> well that's completely out of my scope never worked with that [17:30:49] <mru> good for you [17:31:03] * mru never worked with it either [17:31:08] <mru> I've only done battle with it [17:31:16] <BastyCDGS> lol [17:31:19] <mru> and lost [17:31:35] <av500> Total Physical Source Lines of Code (SLOC) = 597,945 [17:31:44] <av500> 12719 #ifdefs [17:31:51] <av500> fl3.1 [17:32:45] <bilboed> *cough* [17:35:35] <BastyCDGS> how many #if/#elif/#else pairs? [17:35:55] <av500> give me a cmd line and I will run it [17:35:57] * elenril wonders how to handle removing metadata tags [17:36:39] <mru> BastyCDGS: that's a hard question to answer [17:36:41] <mru> they don't all pair up [17:37:02] <elenril> should i realloc/memcpy the array of pointers to tags or just set the pointer to null? [17:37:45] <mru> av500: I get 731615 LOC [17:37:54] <av500> i used sloccount [17:37:56] <mru> 87720 lines starting with # [17:37:58] <mru> so did I [17:38:06] <av500> i grepped for ifdef only [17:38:23] <av500> but your ratio is even worse [17:38:34] <av500> hey, wait a moment, you *left* NDS? [17:38:43] <mru> ssshhh [17:38:48] <av500> lol [17:38:54] <BastyCDGS> :) [17:39:16] <mru> 23452 lines matching #if [17:39:48] <mru> the like #elif and #else a lot [17:39:57] <mru> *they [17:40:03] <BastyCDGS> try a regex like #(.*)if(.*) [17:40:09] <BastyCDGS> that should match if/elif/endif [17:40:39] <av500> 41026 [17:41:26] <BBB> #*if doesn't match #else [17:41:39] <mru> 48050 [17:41:43] <BastyCDGS> #(*if|else) [17:42:03] <av500> mru: how many cpp files do you have? [17:42:52] <av500> in source/ folder [17:43:03] <mru> are they all .cpp? [17:43:15] <mru> 643 *.cpp [17:43:18] <BastyCDGS> did you count header files also .h/.hpp? [17:43:34] <mru> 52763 lines #.*(if|else) [17:43:45] <av500> mru: 600 here, so quite close [17:44:03] <mru> this is labeled 3.1.6 [17:44:27] <av500> 3.1.1 here [17:44:46] <CIA-7> ffmpeg: rbultje * r22932 /trunk/libavcodec/ (acelp_vectors.c amrnbdec.c sipr.c acelp_vectors.h): Split the input/output data arguments to ff_adaptive_gain_control(). [17:46:05] <av500> mru: /scaling_cur_freq: 1000000 :) [17:46:13] <CIA-7> ffmpeg: rbultje * r22933 /trunk/libavcodec/ (acelp_filters.h amrnbdec.c acelp_filters.c sipr.c): Split input/output data arguments to ff_acelp_apply_order_2_transfer_function(). [17:47:48] <CIA-7> ffmpeg: rbultje * r22934 /trunk/libavcodec/sipr16k.c: Make the Sipr16k postfilter function write data into the target/output buffer. [17:47:55] <BastyCDGS> well to be fair, maybe you should sort out #if DEBUG like lines [17:48:07] <av500> lol [17:48:20] <BastyCDGS> :D [17:49:04] <av500> only 2020 [17:50:57] <CIA-7> ffmpeg: rbultje * r22935 /trunk/libavcodec/qcelpdec.c: Implement QCELP postfilter. [17:51:38] <Dark_Shikari> \o/ [17:51:53] <Dark_Shikari> btw, BBB, what were 1/2/3? [17:52:01] <mru> http://pastie.org/928309 [17:52:02] <BBB> Dark_Shikari: see mailinglist [17:52:10] <BBB> Dark_Shikari: 2 (you ranked highest) was my postfilter [17:52:10] <mru> just a taster... [17:52:13] <BBB> Dark_Shikari: 3 was none [17:52:17] <BBB> Dark_Shikari: 1 was ref postfilter [17:52:20] <Dark_Shikari> LOL [17:52:26] <CIA-7> ffmpeg: jai_menon * r22936 /trunk/libavcodec/parser.c: Fix typo. [17:52:30] <Dark_Shikari> now that is fucking funny [17:52:32] <BBB> I was a little surprised that their postfilter made it worse [17:52:34] <Dark_Shikari> I was sure 1 was no postfilter [17:52:34] <BBB> but who cares [17:52:48] <BBB> their postfilter tilts against unfiltered samples, that's a bug [17:52:50] <mru> 1 sounded like it had had a lowpass applied [17:52:51] <BBB> that's probably why [17:53:47] <BBB> anyway, that's all pre-work [17:53:56] <BBB> the real patch is the audio clipping patch which depended on all this [17:54:03] <BBB> quickly testing my compile now [17:54:18] <j-b> I was sure 1 was the worse one... my ears are broken [17:54:21] <BBB> unfortunately it touches internal.h in libavutil/ so now it's rebuilding my whole tree [17:54:38] <BBB> j-b: I think it was, like I said, it does a wrongly implemented filter [17:54:42] <mru> get a faster computer [17:54:43] <BBB> that's very bad [17:54:49] <BBB> give me one [17:54:51] <j-b> BBB: O_o.. [17:54:54] <mru> BastyCDGS: did you check that link? [17:55:02] <BastyCDGS> pastebin? [17:55:15] <mru> the one I posted [17:55:52] <BastyCDGS> that's the last one from you pastie [17:55:57] <BastyCDGS> and yes I checked it [17:55:58] <mru> yeah [17:56:57] <mru> well, do you like ifdefs? [17:58:40] <CIA-7> ffmpeg: rbultje * r22937 /trunk/ (12 files in 2 dirs): [17:58:40] <CIA-7> ffmpeg: Move clipping of audio samples (for those codecs outputting float) from decoder [17:58:40] <CIA-7> ffmpeg: to the audio conversion routines. [18:00:24] <av500> BastyCDGS: and that file has ~7000 lines as well [18:01:17] <BastyCDGS> ifdef's are very good for doing perfomance stuff (removing debug code etc. in optimized release) [18:01:28] <BastyCDGS> and for adding platform dependent stuff [18:02:05] <mru> that's not the way to do it [18:02:28] <CIA-7> ffmpeg: rbultje * r22938 /trunk/libavcodec/ (wmavoice_data.h wmavoice.c): WMAVoice postfilter. [18:02:30] <BBB> hm, my patch queue is empty now [18:02:36] <BBB> let's write new code [18:03:37] <BastyCDGS> I didn't mean usual stuff, more GUI related stuff...sometimes there isn't another way than doing: [18:03:37] <BastyCDGS> #ifdef WXGTK [18:03:37] <BastyCDGS> ... GTK stuff here [18:03:37] <BastyCDGS> #elif WXMSW [18:03:37] <BastyCDGS> ... Win stuff here [18:03:55] <av500> urg [18:04:15] <BastyCDGS> sometimes you want to use controls which aren't available on each other platform [18:04:38] <av500> and ifdef is the only option for that? [18:04:49] <BastyCDGS> surely not [18:04:57] <BastyCDGS> could also be done via configure & makefile [18:06:37] <BastyCDGS> the above way is wxWidget's way of doing it [18:06:41] <BastyCDGS> and it works pretty well [18:06:56] <BastyCDGS> you need them very rarely though [18:06:59] <BBB> wbs: what's the story with the amr parser? [18:07:03] <BBB> wbs: do we still need that? [18:07:41] <BBB> wbs: should I comment on it? [18:08:01] <mru> BastyCDGS: that fragment I showed is 50 lines from 700k [18:08:08] <mru> and it took me a minute or so to find [18:08:08] <BBB> wbs: (my personal opinion is that we should split individual frames of speech codec data, it's too much overhead given taht each frame is like a few bytes at most) [18:08:28] <av500> BastyCDGS: "very rarely" is the key here [18:08:34] <BastyCDGS> oh you were mentioning this regarding to this fragment... [18:08:44] <BastyCDGS> sorry, wasn't clear to me... [18:09:02] <BastyCDGS> your example is of course a perfect one of not doing it ;) [18:09:52] <mru> note the ifdef around one argument to a function call [18:10:10] <mru> and around parts of if/else statements [18:12:01] <mru> now imagine 700k lines of that [18:12:04] <BastyCDGS> TuComposer: 116266 total [18:12:09] <BastyCDGS> .c|.h [18:12:17] <BastyCDGS> mom will count #if stuff [18:12:45] <mru> oh, if you like ifdefs, look at libavutil/intreadwrite.h [18:13:47] <BastyCDGS> TuComposer: 608 lines begin with # [18:14:16] <BastyCDGS> think that's pretty good... [18:14:30] <mru> that's more sane [18:14:33] <BastyCDGS> but that's plain C ;) [18:14:58] <BastyCDGS> but I guess it will be more when TuComposer is ported from amiga ;) [18:15:03] <drv> i worked on one project where the rule was "no #if/#ifdef ever" [18:15:18] <drv> so every line of code always compiled, no bitrotting possible [18:15:25] <drv> but that only works for stuff that can compile on every platform ;) [18:15:29] <av500> it was java? :) [18:15:35] <drv> nah, C [18:15:35] <BastyCDGS> lol [18:17:32] <BastyCDGS> sorry I forgot escaping, it's not 608 lines, but 1569 [18:18:26] <mru> still [18:19:37] <av500> BastyCDGS: I have the same fl codebase and trust me it is ugly [18:19:56] <av500> it reads more like an RCS file that actual source [18:20:11] <BastyCDGS> i was counting #'s in tucomposer [18:20:17] <BastyCDGS> not fl [18:20:38] <av500> and the worst is, it is impossible to know a good combination of #defines to make it compile or even work [18:20:54] <BastyCDGS> 1569 out of 1126266 lines are beginning with # in TuComposer so far [18:21:11] <BastyCDGS> oops 116266 [18:23:20] <kierank> crikey 116k lines [18:26:39] <BastyCDGS> so you see I've ported quite a lot from m68k asm already ;) [18:26:56] <BastyCDGS> I think when the MOD/S3M/XM/IT loaders are ported, too. it will be around 150k [18:27:33] <BastyCDGS> original 100% asm code is around 40k of lines [18:27:56] <Dark_Shikari> 40k lines of pure asm? blegh [18:28:06] <BastyCDGS> all in one file ;) [18:28:24] <BastyCDGS> except the external library loaders (which include MOD/S3M/XM/IT) [18:28:28] <Dark_Shikari> this is what macros are for [18:28:42] <BastyCDGS> I rarely used macros [18:29:00] <BastyCDGS> there isn't even much stuff in TuComposer where macros are really useful [18:29:07] <BastyCDGS> or save lines of code [18:29:08] <Dark_Shikari> function prologue? [18:29:11] <Dark_Shikari> function epilogue? [18:29:20] <BastyCDGS> you don't need that on m68k [18:29:21] <Dark_Shikari> Unless you made it all one function too. [18:29:27] <Dark_Shikari> m68k doesn't have a stack? [18:29:37] <BastyCDGS> of course it has [18:29:45] <jai> ... [18:29:46] <BastyCDGS> but you can save all registers with: [18:29:51] <BastyCDGS> movem.l d0-d7/a0-a6,-(sp) [18:29:55] <BastyCDGS> that's it, one line [18:29:57] <BastyCDGS> restore: [18:30:04] <BastyCDGS> movem.l (sp)+,d0-d7/a0-a6 [18:30:08] <Dark_Shikari> Nice efficiency. [18:30:16] <BastyCDGS> and this is a m68k instruction [18:30:18] <BastyCDGS> not a macro [18:30:53] <Dark_Shikari> well I for one don't like pushing every single register at the start of every function [18:31:48] <BastyCDGS> I even rarely needed movem.l at all [18:31:56] <BastyCDGS> since I pass args on registers [18:32:11] <BastyCDGS> m68k has 8 data regs and 8 address reg (one being stack a7=sp) [18:32:21] <Dark_Shikari> oh dear, separation of data and address regs, fun [18:33:07] <BastyCDGS> you can also do stuff like: [18:33:19] <BastyCDGS> lea buffer(pc),a0 [18:33:19] <BastyCDGS> movem.l d0-d7/a1-a6,(a0) [18:33:30] <BastyCDGS> will write regs d0-d7/a1-a6 to buffer in a0 [18:33:50] <BastyCDGS> d0 will be a0, d1 at a0+4, etc. [18:34:42] <BastyCDGS> or even do funcy stuff like: [18:34:43] <BastyCDGS> movem.l d0-d3/d5/d7/a1/a3-a5,(a0,d4.w*8) [18:35:08] <BastyCDGS> you can choose the registers 100% freely [18:37:00] <BastyCDGS> the latter example working only on 68020 onwards [18:37:10] <BastyCDGS> d4.w*2, *4, *8 were new to 68020 [18:37:14] <Dark_Shikari> isn't RISC great ;) [18:37:21] <BastyCDGS> but plain 68k could still d4.w*1 ;) [18:38:38] <BBB> j-b: lucky bastard, you get to have jai ;) [18:38:46] <BastyCDGS> jump table: [18:38:46] <BastyCDGS> jsr (a3,d4.w*4) [18:38:58] <av500> gsoc_dedup? [18:39:02] <BastyCDGS> if base ptr is a3, d4.w (word) function index [18:40:18] <BastyCDGS> dark_shikari: there is a RISC like version of m68k, called ColdFire [18:40:29] <VideoLAN|j-b> av500: indeed. [18:40:34] <BastyCDGS> it has still some of the original power of m68k but is reduced a lot [18:40:55] <BastyCDGS> cold fire code running on m68k is almost 100% compatible but not the other way around [18:41:30] <BastyCDGS> this applies to binary and source compatilibty [18:43:30] <wbs> BBB: it's not directly needed for anything, but since e.g. the rtp depacktizer can return more than one, it could be needed e.g. if doing a stream copy [18:43:48] <wbs> BBB: and I don't think you need to comment on it, isn't it mainly michael that should ok such stuff? [18:48:24] <BBB> nah... if I ok, he'll ok it [18:48:30] <BBB> but do you really need it for stream copy? [18:48:32] <BBB> I don't think you do [18:48:49] <BBB> all muxers I know chunk multiple frames per packet [18:48:52] <BBB> not 2-3 [18:48:56] <BBB> but more like 10-20 or so [18:49:11] <wbs> at least the mov muxer fails if you feed it a packet with 2 amr frames [18:49:14] <BBB> otherwise you get micropackets of 10 bytes a piece, at a rate of like 300 per second [18:49:17] <wbs> it has an explicit check against it [18:49:19] <BastyCDGS> btw, very nice site about caveats when supporting 64-bit architectures [18:49:20] <BBB> really? that's amazing [18:49:21] <BastyCDGS> http://www.viva64.com/content/articles/64-bit-development/?f=20_issues_of_p… [18:49:23] <wbs> (dating back to 2002 or so ;P) [18:49:31] <BastyCDGS> it's c++ but most of the stuff is also applicable for c [18:50:12] <wbs> the rtp amr packetizer also just wants one packet at a time (but it could of course be improved to handle it) [18:50:33] <wbs> the amr muxer itself should be able to handle it, since it simply writes all packets out sequentially ;P [18:51:48] <Dark_Shikari> wow, that guide basically covers 100 things that no sane programmer should ever do [18:51:51] <Dark_Shikari> >_> [18:52:16] <mru> I have only one rule: don't write non-portable code [18:52:51] <mru> once upon a time, ~2001, I wrote come sloppy code that would only work on 64-bit [18:53:25] <mru> this was before most people had even heard of 64-bit [18:53:42] <peloverde> I still write sloppy code that only works on 64-bit all the time, the format string values for the stdint types are ridiculous [18:54:00] <mru> PRId64 [18:54:22] <DimStar> Hi everybody. I have an issue with openSUSE package building (there are brp checks raising well known warnings to errors and failing the package building). In the specific case I'm not entirely sure how to address it. Can somebody have a look at http://www.pastebin.org/166149 please? [18:54:27] <peloverde> vs %ld [18:54:34] <mru> I agree they're not pretty [18:55:47] <peloverde> anyway outside of the windows world, 64-bit is not considered exotic [18:55:51] <BastyCDGS> mru, the rule itself is clear, but you know sometimes it can be pretty hard to find out if code is really portable ;) [18:55:52] <mru> wtf http://www.facebook.com/rich.felker [18:56:14] <kierank> ? [18:56:20] <mru> didn't expect him on facebook [18:56:31] <wbs> BastyCDGS: after a while you learn to know immediately what's portable and what's not [18:56:38] <mru> he's like the most paranoid person ever [18:56:43] <wbs> and usually people try to point out such things in reviews etc [18:56:50] <mru> if it's in the spec, it's portable [18:56:53] <mru> if not, it's not [18:56:55] <BastyCDGS> mru...when I open your facebook link I just get a user page not found [18:57:30] <mru> works here [18:57:36] <mru> but you probably don't know him anyway [18:58:16] <peloverde> we rely on plenty of non-portable C behavior [18:58:23] <BastyCDGS> wbs, yes of course, experience always makes the stuff ;) [18:58:40] <mru> peloverde: we don't rely on anything with undefined behaviour [18:58:50] <mru> relying on implementation-defined behaviour is often necessary [18:59:00] <peloverde> punning a float to int is architecture dependent [18:59:03] <mru> like two's complement, ieee754 etc [18:59:19] <BastyCDGS> as well is all endianess stuff ;) [18:59:38] <mru> since we take care of endianness properly, that's not a problem [18:59:45] <mru> ok, we don't work on pdp endian [19:00:24] <BastyCDGS> we're experienced and skilled coders so that isn't a wonder, but ask around an IT university ;) [19:00:42] <BastyCDGS> portability isn't teached in the way it should be [19:01:44] <mru> they don't teach c and asm anymore [19:01:56] <mru> one of my classes assumed knowledge of C [19:01:56] <BastyCDGS> very sad :( [19:02:05] <mru> yet they didn't offer a class teaching it [19:02:14] <mru> they assumed everybody would have learned it somehow [19:02:22] <mru> which was true [19:02:29] <peloverde> also don't some files still warn about undefined type punning? or did we fix that? [19:02:41] <mru> I fixed quite a few [19:02:49] <BastyCDGS> peloverde, there are still some [19:02:51] <mru> quite a few remain [19:02:59] <BastyCDGS> just compiled today the whole ffmpeg stuff [19:03:41] <BastyCDGS> maybe I shall support with patches for fixing the remaining stuff? [19:03:56] <mru> it's boring as hell [19:04:39] <BastyCDGS> then even better when I support, so everyone has less to do on that boring stuff ;) [19:05:15] <mru> you have to look for bad casts and replace them with macros from intreadwrite.h [19:05:32] <mru> that file is pure preprocessor mayhem btw [19:05:59] <BastyCDGS> how should I design patches for this the best way? [19:06:03] <BastyCDGS> one patch for one file? [19:06:43] <wbs> one patch per issue [19:06:51] <mru> not one per cast [19:06:55] <mru> that's too many patches [19:07:07] <wbs> that is, one patch for fixing all occurrances of the same issue [19:07:26] <mru> no, that's too much [19:07:40] <mru> one per as-much-as-you-can-manage [19:07:52] <BastyCDGS> for each library? i.e. all libavcodec issues on that in one patch? [19:07:57] <wbs> true [19:08:14] <mru> if you can fix mpegvideo*.c that would be swell [19:09:08] <BastyCDGS> will take a look on it [19:09:16] <DimStar> Hi everybody. I have an issue with openSUSE package building (there are brp checks raising well known warnings to errors and failing the package building). In the specific case I'm not entirely sure how to address it. Can somebody have a look at http://www.pastebin.org/166149 please? [19:09:52] <wbs> DimStar: you said that already. what are brp checks? [19:10:26] <DimStar> wbs: you can also call them lint... it's a package quality system... [19:10:52] <DimStar> Build Result Postprocessing [19:11:03] <wbs> ah, ok [19:11:10] <mru> do not mention lint in my presence [19:11:34] <DimStar> mru :) that's why I say brp :P [19:11:38] <wbs> for those who didn't check the link, there's some "no return statement in function returning non-void" in libswscale [19:11:38] <BastyCDGS> dimstar, looks to me that if the #if define isn't defined the function body gets empty [19:12:05] <BastyCDGS> and therefore returns random values [19:12:08] <mru> those should be fixed [19:12:11] <DimStar> BastyCDGS: yes, that's rather obvious :) the question would be to get a proper solution for it [19:12:35] <mru> why do those functions even exist if the entire body is ifdeffed out? [19:13:41] <DimStar> mru: form what I've seen in yuv*_mmx.c, their call is not preprocessed, but only if (HAVE_7REGS), so if the function won't exist the build would fail completely... (but I might have misread the code). [19:14:17] <DimStar> yuv2rgb_mmx.c, line 67 for example [19:14:22] <mru> if the function does nothing, it is an error to call it [19:14:55] <peloverde> mru, perhaps the code predates requiring DCE? [19:15:08] <BastyCDGS> so put the #if out of the function body? [19:15:18] <BastyCDGS> if that breaks building that should be fixed elsewhere, right? [19:15:21] <mru> peloverde: the code predates the requirement to work? [19:15:41] <mru> this is libswscale, I'm not looking at it [19:15:47] <mru> last time I did, my eyes hurt for a week [19:16:02] <peloverde> no, just predating the requirement for the compiler to remove unreachable code [19:16:12] <peloverde> like if (PREPROCESSOR_DIRECTIVE) {} [19:16:17] <mru> I know what dce is [19:16:35] <peloverde> well your response did not seem to imply that [19:16:41] <DimStar> I mean of course I can do a 'hack fix' with #else return 0 (and hope the function really never ever is called if HAVE_7REGS is not defined)... this would make the compiler happy. [19:17:15] <BastyCDGS> dimstar, have you tested what happens if you put the #if outside the func body? [19:17:24] <BastyCDGS> and do that in the header declaring it, too? [19:17:52] <DimStar> BastyCDGS: actually no, did not test this... I can do that and let you know if you think that should give a valid result. [19:19:03] <BastyCDGS> when HAVE_7REGS is defined at all? [19:20:40] <DimStar> BastyCDGS: libavutil/x86_cpu.h:#define HAVE_7REGS (ARCH_X86_64 || (HAVE_EBX_AVAILABLE && HAVE_EBP_AVAILABLE)) [19:21:04] <BastyCDGS> so that function is empty on all non-x86_64 cpus... [19:21:12] <mru> no [19:22:23] <BastyCDGS> ops yes the || ;) [19:22:38] <BastyCDGS> so it's empty on any non-x86* cpu ;) [19:22:46] <mru> it's x86 asm... [19:22:55] <mru> in the x86/ dir [19:23:41] <BastyCDGS> then it should be safe to just do the if out of the function body... [19:23:52] <BastyCDGS> since it can't be called anyway on non-x86 [19:24:54] <BastyCDGS> if this delivers compile errors that are bugs to be fixed, because calling this from non-x86 is a fatal error then [19:25:46] <BastyCDGS> mru, do you agree on my solution idea? [19:25:54] <mru> try and see what happens [19:26:48] <DimStar> I have created this patch: http://pastebin.com/WXBPd7L8 [19:27:02] <DimStar> will take a while for my build host to pick it up though... can let you know soon. [19:27:42] <BastyCDGS> I'll apply it and test a build, too... [19:34:40] <BastyCDGS> hmm looking at makefile in there this file isn't even compiled [19:35:06] <BastyCDGS> maybe it's just a code generation template for yuv2rgb_mmx.c? [19:36:08] <BastyCDGS> does it need special configure parameters? [19:36:33] <DimStar> BastyCDGS: In file included from libswscale/x86/yuv2rgb_mmx.c:52:0: [19:37:13] <DimStar> kind of uncommon to #include a .c file, but well.... [19:37:16] <Dark_Shikari> not really [19:37:21] <Dark_Shikari> it's how you template in C [19:37:34] <Dark_Shikari> along with other such fun things as ALWAYS_INLINE, __builtin_constant_p, etc [19:37:58] <mru> Dark_Shikari: that's not really C [19:38:02] <mru> that's gcc [19:38:15] <Dark_Shikari> it's still basically C. It's not, say, C++. [19:38:34] <mru> sure [19:39:51] <Dark_Shikari> also, while I'm compiling gcc [19:39:54] <Dark_Shikari> who the hell uses gcj [19:39:59] <mru> nobody [19:40:11] <mru> --enable-language=c,c++ [19:40:25] <Dark_Shikari> lol [19:40:34] <Dark_Shikari> what does it do? [19:40:37] <Dark_Shikari> compile java to x86? [19:40:40] <Dark_Shikari> or java to jvm bytecode? [19:40:40] <Dark_Shikari> or what [19:40:47] <BastyCDGS> dimstar, what are your configure options, it's not in my makefile [19:40:50] <mru> it compiles java to bytecode, java to asm, or bytecode to asm [19:41:31] <DimStar> BastyCDGS: what do you mean it's not in your makefile? the _template.c is #included from the _mmx.c file. (line 52) [19:42:13] <mru> jad is much more useful [19:42:14] <DimStar> BastyCDGS: as such yes: it does not figure in makefile [19:42:18] <mru> it turn bytecode into java [19:42:33] <BastyCDGS> *bangingheadondesk* [19:42:38] <BastyCDGS> yes sorry [19:42:45] <DimStar> BastyCDGS: no worries... [19:43:52] <kierank> is reverse execution in gdb any good? [19:44:07] <mru> never tried it [19:44:08] <BastyCDGS> you mean the new one in GDB 7? [19:44:10] <mru> I assume not [19:44:23] <peloverde> it's awful [19:44:27] <BastyCDGS> probably as useful as walking backwards ;) [19:44:33] <mru> debuggers are mostly useless anyway [19:44:33] <peloverde> it doesn't support the sse fpu [19:44:38] <peloverde> because that's "Exotic" [19:45:18] <BastyCDGS> mru, without it I wouldn't have learned m68k asm ;) [19:45:26] <BastyCDGS> I hadn't a manual about m68k assembly [19:45:40] <BastyCDGS> so I had to find out what the m68k instructions do by stepping with a debugger ;) [19:45:40] <mru> peloverde: just like tying your shoelaces is exotic? [19:46:01] <mru> BastyCDGS: sounds tedious [19:46:15] <BastyCDGS> was 1993, no google search and that's it, didn't even had a modem ;) [19:46:29] <mru> debuggers are useful for looking at core dumps, but that's about all [19:46:40] <BastyCDGS> or for cracking games ;) [19:46:52] <BastyCDGS> + apps ;) [19:47:01] <mru> disassemblers are more useful for that [19:47:26] <BastyCDGS> debuggers contain a disassembler, don't they ;) [19:47:35] <mru> hopefully, yes [19:47:42] <mru> but you don't need the rest of the debugger [19:48:01] <peloverde> Just use Hex-Rays [19:48:45] <peloverde> If you are doing something nefarious you should have no qualms about acquiring it, if you are doing something legit it's well worth the money [19:49:32] <Dark_Shikari> since when is cracking nefarious? [19:49:33] <Dark_Shikari> =p [19:49:42] <mru> sometimes cracking is necessary [19:49:48] <mru> even when you have a licence [19:49:53] <BBB> mru: not 100% true, I use debuggers to dump memory of binaries that I'm disassembling [19:50:02] <BastyCDGS> yes mru [19:50:03] <BBB> but maybe that's "backtrace" again :) [19:50:35] <mru> put it this way, I don't think I've ever solved a problem by stepping through code with a debugger [19:51:01] <BastyCDGS> cracking makes the stuff also more comfortable, never insert a DVD anymore, or search for line x, word y, column z in your handbook [19:51:25] <peloverde> for dealing with segfaults valgrind is usually much more useful [19:53:20] <wbs> peloverde: yeah, valgrind is just fantastic [19:54:15] <_av500_> +1 [19:54:44] <peloverde> now if you really want fun zzuf + valgrind [19:54:47] <BastyCDGS> sorry lost connection [19:54:50] <BastyCDGS> did I miss anything? [19:57:11] <BastyCDGS> btw, building with the patch was successful [19:57:31] <wbs> BastyCDGS: yes, but are you sure that HAVE_7REGS wasn't set in your build? [19:57:56] <wbs> if it was set, your test build doesn't say anything [19:58:42] <BastyCDGS> oh damn, you're right [19:58:52] <BastyCDGS> since I was compiling for x86 it was very probably be set [19:59:51] <BastyCDGS> I haven't a cross-compiler for non-x86 ready [20:00:07] <BastyCDGS> so I probably have to comment out the define [20:24:02] <mru> build for x86 with --enable-pic [20:24:32] <BastyCDGS> 2nd build is almost finished, did comment out HAVE_7REGS in x86_*.h [20:24:40] <BastyCDGS> is linking [20:25:03] <BastyCDGS> build finish and success [20:25:59] <DimStar> Another thing I try again to push: can you extend configure's detection of libxvid to also link libm? In case the libraries are all build with -Wl,-as-needed, this results in undefined references and the detection of libxvid fails. I've been carrying a patch for that forever already. [20:26:51] <BastyCDGS> --enable-pic uses EBP for position indepent code and thus only HAVE_6REGS defined? [20:27:06] <BastyCDGS> shall I retest with --enable-pic anyway? [20:27:39] <DimStar> a patch for xvidocre detection in an entire Wl-as-needed built system: http://pastebin.com/gMgi1fdQ (vs current trunk) [20:28:21] <mru> I still think we should drop xvid support [20:29:02] <BastyCDGS> what's the problem with xvid? [20:29:12] <mru> redundant [20:29:17] <mru> we already have mpeg4 codecs [20:29:21] <_av500_> +1 [20:29:34] <mru> and we've taken their devs too [20:30:18] <BastyCDGS> are the mpeg4 codecs 100% replacement for xvid? [20:31:27] <mru> the decoders do exactly the same thing [20:31:31] <BastyCDGS> meaning removing xvid support doesn't cause lesser avis etc. to be handled by ffmpeg? [20:31:33] <mru> the encoders are of course different [20:31:38] <mru> but they support the same features [20:31:56] <mru> we never decode through xvid anyway [20:32:05] <mru> it's possible to force encoding with xvid [20:33:20] <pJok> mru, can't you just encode with the mpeg4 encoder and select an xvid 4cc? [20:33:44] <mru> xvid encodes a bit better for some kinds of input [20:33:46] <mru> allegedly [20:34:14] <BastyCDGS> then dropping at least the xvid decoder is a good idea [20:34:20] <_av500_> days of mpeg4 encode are over [20:34:35] <mru> we've never supported decoding through xvid [20:39:02] <BastyCDGS> what kind of inputs are handled better with xvid? [20:39:15] <mru> don't know [20:39:20] <mru> don't even know if it's true [20:39:20] <_av500_> l33t dvd r1ps [20:46:36] <BastyCDGS> configure with --enable-pic breaks stuff [20:48:49] <BastyCDGS> can't copy it in here [20:48:59] <mru> with the patch? [20:49:03] <BastyCDGS> yes [20:49:18] <BastyCDGS> error: asm operand has impossible constraints [20:49:38] <BastyCDGS> error: can't find a register in class GENERAL_REGS while reloading asm [20:49:41] <mru> which gcc? [20:49:45] <BastyCDGS> 4.2.4 [20:49:59] <BastyCDGS> both errors in /home/basty/src/ffmpeg-svn/libavcodec/x86/h264dsp_mmx.c:2079 [20:50:36] <BastyCDGS> stop, that's h264...not yuv [20:50:56] <BastyCDGS> there's also a warning [20:51:08] <BastyCDGS> warning: ff_x264_deblock_v_luma_intra_mmxext defined but not used [20:51:20] <BastyCDGS> in file /home/basty/src/ffmpeg-svn/libavcodec/x86/dsputil_mmx.c:2394 [20:51:29] <jai> any opinions on http://pastie.org/928666 [20:51:35] <jai> elenril: ^ [20:52:16] <BastyCDGS> doesn't have to do with the patch from DimStar [20:52:36] <BastyCDGS> at least it looks so ;) [20:52:52] <jai> gcc's RA sucks [20:53:26] <BastyCDGS> can someone of you also do a build with configure --enable-pic with a different gcc? [20:53:27] <mru> gcc's $feature sucks [20:53:32] <BastyCDGS> and confirm this? [20:55:05] <BastyCDGS> gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4) [20:55:16] <BastyCDGS> was causing this here [20:58:30] <mru> similar errors here [20:59:13] <BastyCDGS> I remember some h264 patches recently commited to repository [20:59:21] <BastyCDGS> maybe one of them is causing that... [20:59:37] <mru> x86-32 with pic has always been troublesome [21:00:03] <BastyCDGS> why? [21:00:35] <mru> too few registers and sucky register allocator [21:03:42] <BastyCDGS> well x86-32 has too few regs anyway ;) [21:04:12] <BastyCDGS> but what's the problem with reg alloc? shouldn't it be more or less the same just that ebp is always allocated? [21:06:55] <mru> yes, and that's enough for it to fail [21:07:02] <mru> did I mention it sucks? [21:08:00] <BastyCDGS> yes u did [21:14:58] <hyc> hmm, did borland turbo-C do a better job? [21:19:34] <mru> hard to compare [21:20:03] <mru> and I never studied any of its code [21:20:06] <hyc> I'm having a hard time coming up with alternatives to look at [21:20:14] <hyc> Intel ICC of course [21:20:22] <mru> hand-written code [21:20:22] <CIA-7> ffmpeg: stefano * r22939 /trunk/libavformat/aviobuf.c: [21:20:22] <CIA-7> ffmpeg: Do not initialize res in url_fseek(), in the case !s->seek directly [21:20:22] <CIA-7> ffmpeg: return AVERROR(EPIPE) rather than the pre-defined value of res. [21:20:22] <CIA-7> ffmpeg: Slightly improve readability. [21:20:39] <hyc> sure [21:21:09] <hyc> but really, a compiler ought to be able to track liveness of registers and re-use them efficiently [21:22:12] <bcoudurier> hi guys [21:22:22] <mru> gcc usually fails when you suddenly need lots of registers [21:22:22] <hyc> howdy [21:22:28] <BastyCDGS> hey bcoudurier [21:22:29] <mru> like for entering an asm block [21:22:42] <BastyCDGS> isn't intel planning and going to place more and more of ICC into GCC [21:22:44] <mru> guys, you're talking to a script [21:22:50] <BastyCDGS> remember reading sth. regarding this quite a time ago [21:23:10] <hyc> why would Intel do that? they make a lot of money on ICC [21:23:39] <BastyCDGS> maybe to make gcc produce better code for intel than for AMD? [21:24:05] <hyc> seems kind of silly. it would produce better code for all x86. [21:24:27] <hyc> currently AMD-optimized gcc code runs faster on Intel than Intel-optimized gcc code [21:24:53] <BastyCDGS> wtf!? [21:25:04] <hyc> when you take away the CPUID-specific cheats that ICC uses, it will boost AMD chips too, not just Intel chips. [21:25:24] <hyc> try it some time, I've tested this on a number of programs [21:25:36] <hyc> use -march=amdfamily10 vs -march=core2 [21:25:59] <hyc> the AMD version runs faster on Core2 than the core2 version. [21:26:15] <hyc> and the core2 version runs slower on AMD too, but that's more to be expected. [21:26:33] <BastyCDGS> that's really crazy [21:27:15] <hyc> better open source compiler technology benefits everybody equally. [21:27:21] <hyc> I doubt Intel wants that. [21:28:01] <hyc> They've demonstrated time after time, release after release, that they want to produce superior code on Intel and inferior code on AMD [21:28:10] <BastyCDGS> http://www.phoronix.com/scan.php?page=news_item&px=NzE5Nw [21:28:19] <BastyCDGS> there's an article about intel contribution to gcc [21:28:58] <hyc> a year ago. haven't heard anything since. [21:29:03] <Dark_Shikari> mru: [21:29:09] <Dark_Shikari> s/when you suddenly need lots of registers// [21:29:21] <mru> Dark_Shikari: that's when it usually fails first [21:29:35] <Dark_Shikari> oh my fucking god [21:29:36] <Dark_Shikari> this is brilliant [21:29:37] <Dark_Shikari> http://users.telenet.be/darnley/ffmpeg/coloured_messages.png [21:29:41] <Dark_Shikari> No more users not seeing error messages [21:30:27] <mru> never underestimate the blindness of users [21:30:43] <Dark_Shikari> seriously though, this will help massively [21:31:03] <mru> adding ansi colour codes to av_log should be easy [21:31:18] <Dark_Shikari> error = red [21:31:19] <Dark_Shikari> warning = yellow [21:31:26] <hyc> BastyCDGS: http://www.agner.org/optimize/blog/read.php?i=49 [21:33:13] <hyc> should use termcap/curses tho right? not just hardcoded ANSI [21:33:32] <mru> that's much harder :-) [21:33:45] <hyc> doing things right usually is :P [21:34:24] <BastyCDGS> well I suggest coloring be optional... [21:34:44] <hyc> optional? if it defaults off, naive users will never get any benefit [21:34:56] <hyc> and they're the ones who seem to need it [21:34:59] <BastyCDGS> then it's fine ;) [21:35:31] <BastyCDGS> wasn't clear to me if that was intended to be default on/off [21:38:44] <BastyCDGS> hyc thx for link it contains some details I didn't know yet [21:38:53] <BastyCDGS> I already about that math lib stuff [21:39:20] <Dark_Shikari> we can add -no-color [21:40:14] <BastyCDGS> default is off, why -no-color then, should be -enable-colors more likely? ;) [21:40:39] <Dark_Shikari> no, default is on [21:40:40] <Dark_Shikari> if it's off it's useless [21:40:47] <Dark_Shikari> the sole purpose of this is to help deal with idiots who cannot fucking rea [21:40:50] <Dark_Shikari> *read [21:41:49] <BastyCDGS> wouldn't it better that default is on when it's an interactive terminal and off if you're redirect to file? [21:43:35] <BastyCDGS> like ls does...on interactive terminal ls defaults to colored mode but doesn't do this if ls > /foo/bar [21:46:06] <FUautotools> How about an initial patch: http://pastebin.org/166404 [21:46:29] <Dark_Shikari> a linux patch would be preferred first [21:46:44] <FUautotools> pfft, working on the ansi codes [21:46:59] <Kovensky> AFAIK only mingw needs special care [21:47:24] <Kovensky> for the standard 16 ANSI colors anyway [21:48:20] <BastyCDGS> dark_shikari does it really care which one is finished first? if fuautotools patch does work I don't see any problem [21:49:21] <Dark_Shikari> go try to get it accepted then without linux support ;) [21:54:06] <BastyCDGS> well I can't decide that indeed ;) [21:54:16] <BastyCDGS> but the win32 stuff looks ok to me [21:54:59] <BastyCDGS> based on this patch there will be somebody just changing the linux defines [21:55:13] <Dark_Shikari> no... you have to print extra characters for linux terminal [21:55:41] <BastyCDGS> yes of course, but this can be done in the #defines he left yet empty [21:56:03] <BastyCDGS> fputs ( "ESC[31m" ); etc. [21:56:30] <BastyCDGS> ok fputs was a bad idea because of \n ;) [21:57:20] <hyc> "hey, my default terminal background color is red. this sucks." [21:58:10] <FUautotools> I need to set the bg then too.... [21:59:36] <BastyCDGS> or choose the color from /dev/urandom *gg* [21:59:50] <BastyCDGS> then you have a 1/16 chance that it doesn't interfere with your bg col ;) [22:00:14] <FUautotools> If I set only the fg colour with ansi codes, does the bg remain at its previous colour? [22:00:31] <BastyCDGS> yes it does [22:00:54] <FUautotools> go go gadget background_black [22:01:28] <BastyCDGS> or you make the bg color configurable someway [22:01:36] <BastyCDGS> fg color oops [22:01:41] <FUautotools> Yeah, at compile time [22:01:41] <BastyCDGS> or both ;) [22:04:26] <hyc> or you just define an algorithm/mapping for high contrast, and choose colors based on the current settings. [22:04:43] <hyc> this isn't rocket science, it's easy stuff. [22:06:29] <BastyCDGS> but as said it should only be on by default if it's an interactive terminal...FUautotools patch does this for win32 [22:06:51] <BastyCDGS> since the win32 calls only affect a console window [22:07:11] <BastyCDGS> if stderr points to a file the color info isn't put in the file [22:08:06] <hyc> I wonder if this works with other win32 terminals, like rxvt [22:08:40] <hyc> probably better to just emit ASNI escape codes. doesn't the default console have ANSI.SYS built in now? [22:08:42] <BastyCDGS> not sure about this, would have to look MSDN for that [22:09:02] <FUautotools> no [22:09:37] <BastyCDGS> I'm just checking with wine cmd.exe, one moment... [22:11:24] <BastyCDGS> http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en… [22:11:40] <BastyCDGS> seems that you have to pass /a to cmd.exe [22:13:11] <BastyCDGS> lol [22:13:13] <BastyCDGS> http://www.netikka.net/tsneti/info/tscmd051.htm [22:13:52] <BastyCDGS> you can use qbasic ^^ [22:14:29] <FUautotools> now featuring ansi codes: http://pastebin.org/166455 [22:17:10] <BastyCDGS> instead of %c..., 27 use \033 [22:17:16] <BastyCDGS> \033[31m e.g. [22:17:22] <FUautotools> Oh yeah, that's it [22:18:03] <hyc> ANSI codes work by default when I run wine cmd.exe [22:18:40] <BastyCDGS> yes but the question is if wine uses the linux terminal capabilities in that case [22:19:15] <BastyCDGS> I can try on my laptop with windows 7 if you wish [22:19:57] <FUautotools> On windows they're not supported by default [22:21:28] <FUautotools> nor do they seem to be supported with the /a switch [22:21:44] <BastyCDGS> but still win/linux behave different on your patch, linux will output the color values to a redirected file [22:21:47] <BBB> mru: ping [22:22:03] <FUautotools> Link me to the linux equivalent then [22:23:27] <hyc> call isatty() first [22:23:47] <hyc> though frankly I don't see a problem with outputting to a file [22:23:57] <hyc> if someone cats the file, then they'll get the colors again. [22:24:11] <FUautotools> What #include do I need? [22:24:24] <BastyCDGS> but then win32 and linux behave differently in that, that can be confusing if you're working on multiple platforms [22:25:30] <BastyCDGS> I think the cleanest and expected way is it do it like the ls command [22:25:41] <BastyCDGS> ls also doesn't out color codes if it's not a tty [22:25:50] <FUautotools> What #include do I need? [22:26:13] <BastyCDGS> <unistd.h> [22:26:22] <BastyCDGS> http://www.opengroup.org/onlinepubs/009695399/functions/isatty.html [22:27:49] <BastyCDGS> btw, is unistd.h available on macos x too? [22:27:59] <BastyCDGS> someone here with macos coding experience? [22:28:01] <astrange> mac os x is unix [22:28:41] <BastyCDGS> then the patch should be fine [22:28:44] <BBB> several of us use macosx here [22:28:53] <Dark_Shikari> everything is unix except windows [22:28:58] <Dark_Shikari> (and, like, plan 9) [22:29:18] <BastyCDGS> yes it would work even on amigaos shell [22:29:57] <BastyCDGS> except the isatty...on amiga you'd have to call dos.library/IsInteractive instead [22:30:08] <BastyCDGS> but amigaos as ixemul.library for such cases ;) [22:31:11] <BastyCDGS> is OS/2 a target platform of ffmpeg? [22:31:34] <BastyCDGS> (well I doubt that anyone here would revoke the patch just of that) ;) [22:32:17] <FUautotools> Better? http://pastebin.org/166467 [22:33:10] <BastyCDGS> looks fine to me... [22:33:36] <FUautotools> I assume isatty(stderr) works [22:34:15] <FUautotools> oh, small error fixed http://pastebin.org/166469 [22:35:41] <BastyCDGS> compiling a small sample: /tmp/test.c:6: attention : passing argument 1 of «isatty» makes integer from pointer without a cast [22:39:46] <BastyCDGS> use [22:39:47] <BastyCDGS> fileno(stderr) [22:39:57] <BastyCDGS> isatty(fileno(stderr)) [22:40:37] <BastyCDGS> fileno is stdio.h [22:41:07] <FUautotools> ... ok [22:44:32] <BastyCDGS> anyone want to comment how i reviewed the patch? [22:45:23] <BBB> stderr=2 [22:45:33] <BBB> so just isatty(2) is the same as isatty(fileno(stderr)) [22:45:39] <BBB> smaller ;) [22:45:56] <BastyCDGS> but less readable ;) [22:46:15] <BastyCDGS> is it safe to assume that stderr is always 2? [22:46:22] <hyc> yes [22:46:23] <BastyCDGS> on all unices? [22:46:28] <hyc> that is it's definition [22:46:38] <hyc> 0,1,2 are all set in stone [22:47:25] <FUautotools> even on windows... [22:48:39] <FUautotools> BBB: Do you want it replaced by 2? [22:49:04] <BBB> use 2 /* stderr */ if you're worried about readability [22:50:02] <FUautotools> _I'm_ not [22:51:11] <FUautotools> but then one could say that all "stderr"s should be replaced by 2 [22:51:24] <BastyCDGS> no stderr is FILE * [22:51:30] <FUautotools> oh... [22:51:32] <BastyCDGS> it's a pointer not an int [22:53:24] <FUautotools> Has everything I've real really skipped the fact that they're FILE *? [22:53:35] <FUautotools> s/real/read [22:54:46] <mru> BBB: pong [22:55:01] <BastyCDGS> what have you read? [22:56:27] <BastyCDGS> hey saste, how are u? [22:57:51] <BBB> mru: what was that project that you wanted to give a soc slot to again? [22:57:52] <FUautotools> BastyCDGS: lots on the net, several O'Reilly books, some not O'Reilly books [22:58:23] <hyc> the variables stdin, stdout, and stderr are <stdio.h> handles, i.e. FILE*s [22:58:26] <mru> BBB: he's getting a slot after all [22:58:31] <mru> priorities were altered [22:58:35] <BBB> ? [22:58:36] <BBB> who? [22:58:39] <BBB> oh, ok [22:58:46] <BBB> sorry, my brain dysfunctioned for a second [22:58:52] <hyc> but standard input is "whatever is attached to filedescriptor 0" and so on [22:59:05] <BBB> ok, I'll leave the rest for goog then [22:59:07] <saste> hey basty [22:59:08] <mru> he got more votes later on [23:00:39] <Dark_Shikari> what is the tab key in single-character form for comparison? [23:00:43] <Dark_Shikari> e.g. '\n' is newline [23:00:46] <Dark_Shikari> in C [23:00:47] <mru> \t [23:00:49] <Dark_Shikari> k, thx [23:01:11] <mru> aka 'I'-0x40 [23:01:20] <mru> aka ^I [23:01:26] <hyc> \010 in octal [23:01:31] <hyc> hm [23:01:42] <hyc> no \010 is backspace [23:01:48] <mru> \011 [23:01:49] <BBB> j-b: want an extra slot? [23:01:55] <Dark_Shikari> we have, like, 15 [23:01:55] <BBB> Dark_Shikari: or x264 extra slot? [23:01:57] <Dark_Shikari> I think we have enough [23:02:01] <Dark_Shikari> x264 has way enough [23:02:01] <BBB> hm... [23:02:03] <BBB> ok [23:02:10] <Dark_Shikari> we only have 3 students accepted ffs [23:02:57] <BastyCDGS> really? so andoma, FUautotools and me are the only? [23:03:10] <Dark_Shikari> For x264. [23:03:11] <Dark_Shikari> Not ffmpeg. [23:04:53] <BastyCDGS> how many students are then for ffmpeg in total? [23:05:31] <kierank> FUautotools: what are you doing in gsoc? [23:05:33] <BastyCDGS> FUautotools, what the book wrote about file? [23:05:47] <FUautotools> I'm not a student [23:05:54] <BastyCDGS> oh then I was wrong, sorry [23:05:55] <kierank> ah ok [23:06:05] <BBB> BastyCDGS: andoma is your mentor [23:06:15] <BBB> BastyCDGS: you have 6 colleagues, if my counting is right [23:06:18] <BastyCDGS> ups seems I mixed sth. up ;) [23:06:19] <FUautotools> I wish I could get 5k from google for some work though [23:06:22] <BBB> BastyCDGS: you'll meet them later [23:07:37] * BBB goes eat [23:07:48] * BastyCDGS goes to sleep very soon [23:09:58] <BastyCDGS> so I wish you all a wonderful night and nice dreams ;)

1 0

IRC log for 2010-04-20
by irc＠mansr.com 21 Apr '10

21 Apr '10

[00:12:41] <ramiro> what's a good codec to test threading performance? I'm doing -vcodec mpeg4 -threads x -an -y output.mpg [00:26:37] <bcoudurier> mpeg-2/mpeg-4/dnxhd I believe [00:28:51] <ramiro> ok, I'll do fine with mpeg-4 then. any other suggestions? (like high bitrates or whatnot) [00:29:22] <ramiro> hmm, GetProcessTimes seems to add up all threads' times, which is useless for testing this... [00:33:57] <astrange> i don't think mpeg4 works [00:34:15] <astrange> encoding does but not decoding [00:34:35] <astrange> mpeg2 or dv/dnxhd can always use threaded decoding [00:40:49] <bcoudurier> Yuvi are you around ? [00:45:35] <ramiro> should I prefer threaded decoding or encoding? [01:04:19] <Yuvi> bcoudurier: pong [01:04:46] <bcoudurier> do you want to write nero chapters by default ? [01:05:12] <Yuvi> I think so, they're in udta so should be ignored by anything that doesn't recognize them [01:05:54] <bcoudurier> ok [01:06:10] <bcoudurier> also I think the fields are better named tref_id [01:06:21] <bcoudurier> also tref_tag will be needed [01:06:32] <bcoudurier> because other tracks than chapter can ref [01:06:48] <bcoudurier> make tref_tag generic if you see what I mean [01:06:57] <Yuvi> sure [01:07:14] <bcoudurier> I know that at least timecode track use it [01:07:42] <bcoudurier> also the arg name is confusing, it is a MOVTrack, so name should be track and not mov [01:08:03] <Yuvi> just copied the some other function ;) [01:08:15] <bcoudurier> I figured :) [01:08:38] <Yuvi> huh, the *one* function that does taht apparently [01:12:50] <bcoudurier> btw I think I finished the ogg interleaving patch [01:13:02] <bcoudurier> it was a bit more complicated because the page interleaving [01:13:12] <bcoudurier> and I wanted to try to achieve the least overhead possible [01:13:44] <bcoudurier> so I reworked the demuxer to buffer data without using an interleaving function [01:14:47] <Yuvi> demuxer? [01:14:53] <bcoudurier> err muxer [01:15:10] <Yuvi> ah, nice [01:15:12] <bcoudurier> one annoying thing is that without frame duration [01:15:21] <bcoudurier> stream copy fails sometimes [01:15:36] <Yuvi> too much stuff doesn't have frame duration to be able to rely on it [01:22:41] <bcoudurier> well hopefully ogg won't go to mp4 [01:41:49] <CIA-7> ffmpeg: bcoudurier * r22916 /trunk/libavformat/mp3.c: Set AVFMT_NOTIMESTAMPS flag for mp3 muxer [01:43:51] <bcoudurier> Yuvi, can you set PARSE_HEADERS in mkv demuxer ? [01:43:52] <bcoudurier> for audio [01:44:04] <bcoudurier> also I believe setting frame size to 1024 for aac is reasonable [01:44:30] <bcoudurier> that should fix many stream copy errors [02:20:58] <astrange> ramiro: try to measure wallclock time and not user time [02:21:07] <astrange> it's better for measuring multiple threads [02:30:11] <ramiro> what's wallclock time and how do I measure it? [02:30:34] <ohsix> look at a clock on the wall [02:30:51] <ramiro> I can't read the pointers =( [02:30:54] <ohsix> or the realtime clock in your pc :> [02:33:01] <ramiro> good night... [02:33:53] <ohsix> i hope he didn't take that the wrong way [02:36:06] <astrange> er, av_gettime is wallclock time [02:36:08] <astrange> i guess that solves that [03:02:17] <bcoudurier> Yuvi, are you dead ? [03:23:26] <drv> the wiki small tasks page still has a task about making the GIF encoder use LZW [03:23:30] <drv> i thought somebody wrote that already [03:31:17] <bcoudurier> drv, yes it's been done [03:38:28] <drv> ok, removed, thanks [03:39:13] <bcoudurier> you're welcome [04:11:39] <ohsix> :O https://launchpad.net/ubuntu/+source/ffmpeg/4:0.5+svn20090706-2ubuntu2.1 [06:47:26] <Dark_Shikari> http://rs162.rapidshare.com/files/377917771/Chase_sample.avi <--when decoding this video with lavf, the last frame has a timestamp of -1. [06:47:51] <Dark_Shikari> this probably shouldn't happen given that it's a CFR AVI. [07:03:07] <av500> hmm, not here [07:04:12] <av500> 9976ms with lavf [07:05:08] <Dark_Shikari> both ffms and x264's lavf modules have this issue [07:05:10] <Dark_Shikari> how did you measure it? [07:05:47] <Dark_Shikari> oh, we're using reordered_opaque [07:07:01] <Dark_Shikari> i.e. c->reordered_opaque = pkt->pts; before decode_video2 [07:07:15] <Dark_Shikari> then later on [07:07:16] <Dark_Shikari> if( frame->reordered_opaque != AV_NOPTS_VALUE ) p_pic->i_pts = frame->reordered_opaque; [07:07:51] <tetsuo--> ohsix is that still relevant? [07:08:31] <ohsix> tetsuo--: just posted today [07:09:00] <tetsuo--> i just noticed [07:10:09] <tetsuo--> but if that is really based on the old version of ffmpeg those fixes could be backports from current head [07:10:27] <ohsix> could, but the cves are from 2009 too [07:11:41] <tetsuo--> good point [07:13:07] <superdump> cves? [07:16:01] <ohsix> superdump: numbers assigned for security issues http://cve.mitre.org/ the link i posted was a package update for ffmpeg in ubuntu [07:16:16] <superdump> ah [07:18:10] <peloverde> It looks like a lot of them reference branch commit numbers [07:18:54] <tetsuo--> this is the patch: http://launchpadlibrarian.net/44838080/ffmpeg_4:0.5%2Bsvn20090706-2ubuntu2_… [07:19:40] <ohsix> woo 2010 [07:20:49] <av500> Dark_Shikari: if you run it through the decoder, its another story, but what comes out of lavf seems ok to me [07:21:16] <Dark_Shikari> av500: well the decoder shouldn't change pts... [07:21:29] <Dark_Shikari> also, what's a good way to sum up a list of numbers in bash? [07:21:38] <thresh> expr? [07:21:53] <Dark_Shikari> I mean a very long list of numbers in a file, without +s [07:21:56] <av500> excel? [07:22:02] <Dark_Shikari> millions of numbers [07:22:05] <Dark_Shikari> excel maxes at 2^16 [07:22:22] <Dark_Shikari> I could use sort and uniq and sum manually but there must be a better way [07:24:19] <av500> Dark_Shikari: where is above src code line from? [07:24:40] <Dark_Shikari> x264's lavf input module [07:24:46] <Dark_Shikari> it's a very very trivial lavf/lavc wrapper [07:25:00] <Dark_Shikari> that basically does things The Way You're Supposed To Write a Generic Lavf Wrapper [07:25:16] <Dark_Shikari> ffms has the same problem, so I don't think it's our mistake [07:25:20] <Dark_Shikari> since they were developed independently [07:28:50] <hyc> re: summing numbers, use a (while loop; read x; sum=exprsum+x) < list_of_numbers [07:29:06] <hyc> obviously that's just the vague idea [07:29:35] <Dark_Shikari> is there a way to make that into a piped expression? [07:29:38] <Dark_Shikari> i.e. app | sumnumbers [07:29:46] <Dark_Shikari> i.e. is there a "while read standard input"? [07:30:00] <ohsix> perl has @_ [07:30:01] <hyc> shell "read" only reads from stdin [07:30:10] <hyc> so that's already what you want [07:30:37] <Dark_Shikari> so I can do "while read x" ? [07:30:41] <hyc> no [07:30:52] <hyc> like I said, that was only the vague idea. you'll need to get the correct syntax yourself. [07:31:03] <hyc> sounds like you need to spend some quality time with the sh manpage [07:31:05] <ohsix> the ()'s matter too [07:31:44] <Dark_Shikari> blegh [07:31:53] <Dark_Shikari> anyways, already confirmed my results via manual summing with uniq/osrt [07:31:55] <Dark_Shikari> *sort [07:31:59] <Dark_Shikari> since it's like 8 different values [07:34:55] <av500> Dark_Shikari: so frame->reordered_opaque comes back with -1? [07:35:21] <CIA-7> ffmpeg: mstorsjo * r22917 /trunk/libavformat/ (rtpdec.h rtsp.c rtpdec.c): [07:35:21] <CIA-7> ffmpeg: Revert svn rev 21857, readd first_rtcp_ntp_time in RTPDemuxContext [07:35:21] <CIA-7> ffmpeg: In order to sync RTP streams that get their initial RTCP timestamp at [07:35:21] <CIA-7> ffmpeg: different times, propagate the NTP timestamp of the first RTCP packet [07:35:21] <CIA-7> ffmpeg: to all other streams. [07:35:22] <CIA-7> ffmpeg: This makes the timestamps of returned packets start at (near) zero instead [07:35:23] <CIA-7> ffmpeg: of at any random offset. [07:35:58] <Dark_Shikari> av500: I think so. let me make sure [07:36:02] <Dark_Shikari> x264 actually does the following: [07:36:06] <Dark_Shikari> if( frame->reordered_opaque != AV_NOPTS_VALUE ) [07:36:06] <Dark_Shikari> p_pic->i_pts = frame->reordered_opaque; [07:36:06] <Dark_Shikari> else if( pkt->dts != AV_NOPTS_VALUE ) [07:36:06] <Dark_Shikari> p_pic->i_pts = pkt->dts; [07:36:12] <Dark_Shikari> i.e. if pts is invalid, it uses dts instead [07:36:20] <Dark_Shikari> because AVI files return junk pts with lavf [07:36:48] <Dark_Shikari> (sometimes, not sure if it's always) [07:37:05] <av500> me "wrapper" uses dts [07:37:11] <av500> my [07:37:22] <Dark_Shikari> isn't that rather wrong? [07:37:44] <av500> maybe, but I dont use the wrapper :) [07:38:23] <Dark_Shikari> lol [07:38:34] <Dark_Shikari> I suspect this is just an issue of packed b-frames [07:38:42] <Dark_Shikari> and the resultant pts/dts munging [07:39:48] <CIA-7> ffmpeg: mstorsjo * r22918 /trunk/libavformat/ (rtpdec.h rtsp.c rtpdec.c): [07:39:48] <CIA-7> ffmpeg: Reset RTCP timestamps after seeking, add range start offset to the packets timestamps [07:39:48] <CIA-7> ffmpeg: If these aren't reset, the timestamps make a huge jump when the next RTCP [07:39:48] <CIA-7> ffmpeg: is received. [07:39:49] <av500> for last frame I get from lavf: dts/pts 9976/ 0 [07:40:00] <Dark_Shikari> 0 sounds like a problem [07:40:31] <Dark_Shikari> I really don't want to have to swap to haali's splitter for avi here [07:40:40] <Dark_Shikari> lavf shouldn't suck this much [07:42:50] <av500> who does handle packed B in lavf/c? the format or the decoder? [07:42:54] <av500> ok, looks like lavf outputs the whole P+B frame [07:43:08] <av500> well, its not lavf, lavf does not return -1 [07:43:31] <superdump> Dark_Shikari: look up munging on urbandictionary [07:43:55] <av500> http://pastebin.com/LGgp2k6g [07:43:59] <Dark_Shikari> "obfuscation" [07:44:01] <Dark_Shikari> oh, munging, not munge [07:44:02] <av500> this is what I get from lavf on this file [07:44:06] <Dark_Shikari> LOL [07:44:17] <Dark_Shikari> gotta love urbandict [07:44:20] <superdump> mmm [07:44:22] <superdump> :) [07:45:41] <Dark_Shikari> av500: that's retarded [07:45:52] <Dark_Shikari> wait. 599 packets? [07:45:56] <Dark_Shikari> the video has 300 frames. [07:46:30] <av500> yes, and a bunch of nocodes for the packed-bs [07:46:37] <av500> all those 7 byte ones [07:47:25] <Dark_Shikari> weee, more code outside of lavf to work around lavf deficiencies [07:47:48] <av500> you want lavf to drop the nocode frames? [07:48:18] <Dark_Shikari> lavf should never, ever, ever, ever, ever [07:48:20] <Dark_Shikari> ever ever ever ever ever [07:48:23] <Dark_Shikari> return non-monotonic pts after reorder [07:48:24] <av500> ever? [07:48:29] <Dark_Shikari> it is completely nonsensical [08:02:54] <av500> Dark_Shikari: http://pastebin.com/feVVeWdA [08:03:06] <av500> this is a printf from ffplay, pre and post decode_video2 [08:03:19] <av500> I dont see the ts going to -1 [08:03:48] <Dark_Shikari> isn't -1 AV_NOPTS_VALUE? [08:04:18] <Dark_Shikari> or wait, that big thing is right [08:05:05] <Dark_Shikari> either way regardless of the specifics, things are borken =p [08:15:27] <av500> -9223372036854775808 is 0x800000000.... and is AV_NOPTS_VALUE [08:20:39] <merbanan> av500: I'm in estonia now [08:20:52] <superdump> ? [08:21:02] <av500> merbanan: glad you made it :) [08:21:08] <superdump> why? [08:21:49] <av500> the ship made it through the ash cloud [08:22:10] <superdump> i would think boats would be somewhat below the ash cloud [08:23:25] <av500> sneaky ash cloud these days :) [08:26:06] <thresh> you never know where it will strike next. [08:27:49] <jai> lol [09:45:00] <siretart> hi DonDiego [09:58:07] <Dark_Shikari> google's resident village idiot on why they refuse to report bugs to ffmpeg [09:58:10] <Dark_Shikari> 17:57 <@Dark_Shikari> you need legal approval to upload freely available video files? [09:58:14] <Dark_Shikari> 17:57 <@Dark_Shikari> Even creative commons video files? [09:58:16] <Dark_Shikari> 17:57 < fbarchard> yes [09:58:19] <Dark_Shikari> 17:57 < fbarchard> yes [09:58:21] <Dark_Shikari> 17:57 <@Dark_Shikari> Even public domain video files? [09:58:24] <Dark_Shikari> 17:57 < fbarchard> yes [09:58:34] <Dark_Shikari> "We'll complain about sync issues all day but we'll never upload any test samples or report any bugs!" [09:58:42] <Dark_Shikari> fucking hell. [09:59:55] <bilboed-pi> erf [09:59:59] <bilboed-pi> google or youtube ? [10:00:02] <Dark_Shikari> google [10:00:21] <Dark_Shikari> also, this is the resident idiot who thinks you can measure audio quality with psnr [10:00:49] <bilboed-pi> ... [10:01:05] <Dark_Shikari> also, he did a vp8 - x264 comparison and screwed up in about 10 different ways, getting 10 contradictory results [10:01:25] <bilboed-pi> was gonna ask, do they actually have any competent multimedia guy in house ? [10:01:45] <Dark_Shikari> Sure, they have pascal, at yotuube at least [10:01:48] <Dark_Shikari> but this guy is a complete moron [10:02:00] <Dark_Shikari> worse than merely stupid, no common sense and an unwillingness to listen to people who know more than he does [10:02:05] <Dark_Shikari> refuses to even learn [10:02:33] <av500> Dark_Shikari: this comparison, where? [10:02:41] <Dark_Shikari> not published, I just walked him through it over irc [10:02:47] <Dark_Shikari> he managed to screw up everything from fps to luma levels [10:03:14] <av500> VP8 fps is better than h264 luma level? :) [10:03:26] <Dark_Shikari> every day I trust google less to do anything right [10:03:32] <Dark_Shikari> it seems they've screwed themselves over by hiring idiots [10:04:07] <av500> I guess all the google interview riddles are known by now :) [10:04:49] <Dark_Shikari> 18:00 < Tjoppen> then just grab something from archive.org? they're bound to have something in the public domain [10:04:53] <Dark_Shikari> 18:03 < fbarchard> Tjoppen: thanks for the suggestion. I'll bounce that off our lawyer, but I suspect no [10:05:00] <Dark_Shikari> *headdesk* [10:05:04] <av500> gee [10:05:08] <bilboed-pi> ROFL :) [10:05:08] <Tjoppen> heh [10:05:10] <kierank> he is just paranoid [10:05:13] <Dark_Shikari> no, he is stupid [10:05:19] <Dark_Shikari> he has proven at least half a dozen times that he is a clueless retard [10:05:32] <Dark_Shikari> who can be told something 20 times and still not even remember that you told him it [10:05:58] <Tjoppen> lunch. I'll see how this unfolds later [10:06:04] <Dark_Shikari> oh it'll unfold as usual [10:06:06] <Dark_Shikari> he'll complain about bugs in ffmpeg [10:06:07] <Dark_Shikari> report no bugs [10:06:08] <Dark_Shikari> and then leave [10:06:12] <Dark_Shikari> and then come back one week later and repeat the process [10:06:16] <Dark_Shikari> until someone bans him [10:06:18] <Kovensky> kind of unrelated: is there any audio metric other than 'sounds good' btw? [10:06:22] <Dark_Shikari> PEAQ [10:06:43] <Dark_Shikari> re audio quality, we literally got the xiph devs to tell him he was an idiot [10:06:47] <Dark_Shikari> and he still ignored them [10:07:15] <av500> you cant blame him for that :) [10:07:40] <Dark_Shikari> well you know, they're only the developers of the best open source audio encoder [10:07:44] <Dark_Shikari> but hey, what would they know [10:14:43] <merbanan> yeah they are real audio noobs [10:16:23] <superdump> the public domain / creative commons content thing is completely stupid [10:17:08] <bilboed-pi> superdump, you mean that google guy wanting to go through lawyer to use it ? :) [10:18:47] <bilboed-pi> Dark_Shikari, considering I couldn't find a single open-source/free implementation of PEAQ... I'm guessing nobody's using it :) [10:20:08] <mru> who wrote the vorbis encoder? [10:20:21] <av500> al gore? [10:20:36] <mru> no, he invented the internet [10:20:47] <av500> which he needed to spread vorbis! [10:20:48] <bilboed-pi> that was on the first day [10:20:55] <bilboed-pi> on the second day he wrote vorbis [10:21:05] <j-b> on the third he wrote Linux ? [10:21:21] <mru> and then he invented global warming [10:21:44] <bilboed-pi> j-b, tss, he *conceived* Linus [10:22:09] * bilboed-pi thought he invented global warming on sunday [10:22:12] <j-b> bilboed-pi: how silly I am [10:22:16] <bilboed-pi> :) [10:23:19] <superdump> hang on... what day is it? [10:27:01] <av500> 110 [11:54:09] <towolf> Hello, Attila Kinali has blocked my ISP HanseNet from accessing ffmpeg.org. It’s been three weeks. He told me the ban (some guy leeched samples, or something) would be lifted next time the server is rebooted, which might be no earlier than next year. What kind of network administration habits is this? [11:55:20] <merbanan> towolf: you have to email him [11:55:33] <merbanan> we have no power over the server [11:55:58] <merbanan> and we need to protect our server against abuse [11:56:11] <merbanan> or we might need to pay for the hosting [11:59:04] <towolf> merbanan, i mailed him. he told me to wait for next reboot or use proxy and didn’t follow-up otherwise. [11:59:31] <merbanan> ok [12:00:10] <towolf> Isn’t it odd that someone might want to look at www.ffmpeg.org, but it only comes back with an error? HanseNet is not that small. [12:00:39] <mru> complain to them [12:00:53] <mru> tell them abusive customers are causing disruptions for everybody [12:01:03] <mru> and suggest they do something about such people [12:01:05] <jai> hmm [12:01:07] <jai> elenril: ping [12:01:08] <kierank> contact their abuse email [12:01:20] <kierank> and get the time and ip of the abuser [12:01:33] <towolf> kierank, why me? i’m impartial to abuse. i just want to pull from git repo. [12:01:46] <elenril> jai: pong [12:01:52] <towolf> kierank, how would i do that? that’s the job of the admin??? [12:02:05] <kierank> towolf, you could use mru's git if he doesn't have a problem with that [12:02:07] <peloverde> towolf, there are plenty of mirrors of the git repo [12:02:21] <jai> elenril: do you have any plans of adding uslt parsing to our id3 code :) [12:02:22] <peloverde> mru's is actually better in many ways [12:02:28] <towolf> peloverde, have a url? [12:02:38] <elenril> jai: what's uslt ;) [12:02:40] <peloverde> http://git.mansr.com/ [12:02:45] <towolf> peloverde, merci. [12:02:54] <elenril> ah, lyrics [12:02:59] <jai> elenril: stores lyrics without sync info [12:03:17] <jai> elenril: fyi, https://roundup.ffmpeg.org/issue1772 [12:04:52] <jai> bbl [12:16:47] <Kovensky> http://repo.or.cz/FFmpeg-mirror.git [12:20:49] <BastyCDGS> greetings [12:22:19] <Kovensky> saluton [12:22:59] <thresh> The requested URL /FFmpeg-mirror.git was not found on this server [12:23:28] <peloverde> siretart, Do you know if Canonical's MPEG protection licenses cover PPAs or just Ubuntu proper? [12:23:31] <Kovensky> oh [12:23:32] <Kovensky> git:// [12:23:33] <Kovensky> not http:// [12:23:57] <thresh> fatal: The remote end hung up unexpectedly :D [12:26:15] <Kovensky> :V [12:28:07] <DonDiego> Dark_Shikari: btw, frank barchard is also the guy who keeps top-posting every other time he posts to ffmpeg-devel.. [12:28:19] <siretart> peloverde: what MPEG protections are you talking about? [12:28:38] <peloverde> I'm using "protection" as a euphemism for patent licenses [12:29:16] <av500> hmm, where would a mortal find the sample file mentioned here: https://roundup.ffmpeg.org/issue1772 [12:29:17] <Kovensky> DonDiego: well, that's a perfect match for D_S's definition of barchard =p [12:29:19] <iive> peloverde: somebody removed the wording "extortion" from ffmpeg site. [12:29:43] <siretart> I have no inforamtion that canonical had anything mpeg related licensed [12:30:12] <peloverde> I see them on the list of license holders at both Via and MPEG-LA [12:30:21] <peloverde> thanks anyway [12:30:50] <siretart> peloverde: do you have an url to that list? [12:31:05] <av500> peloverde: do they ship something mpeg-la related in stock ubuntu? [12:31:50] <peloverde> http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx [12:31:51] <av500> siretart: http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx [12:32:24] <DonDiego> interesting [12:32:35] <siretart> I'm... suprised [12:32:50] <peloverde> I guess they aren't AAC licensees: http://www.vialicensing.com/licensing/AAC_Licensees.cfm [12:32:58] <peloverde> though the Queen is [12:33:03] <DonDiego> http://www.mpegla.com/main/programs/VC1/Pages/Licensees.aspx [12:33:25] <DonDiego> http://www.mpegla.com/main/programs/M4V/Pages/Licensees.aspx [12:33:26] <siretart> need to write the TB for clarification [12:33:47] <siretart> DonDiego: when shall we create the 0.6 branch? [12:34:02] <DonDiego> TB == ?? [12:34:16] <peloverde> av500, IIRC FFmpeg is in main, though not on the CD [12:34:46] <DonDiego> siretart: i'd say any moment that fate turns green [12:34:51] <siretart> TB == ubuntu technical board [12:35:23] <DonDiego> right now i see quite a few tests failing, i'm not sure if they're supposed to fail or not [12:35:42] <siretart> DonDiego: we don't need to take HEAD, we can also take arevision where fate was green [12:36:05] <kierank> [13:33] <@peloverde> though the Queen is --> lol [12:36:46] <DonDiego> siretart: well, but the ogg and theora fixes went in just a short while ago [12:37:01] <siretart> DonDiego: backportable... [12:37:19] <DonDiego> peloverde: just to doublecheck: anything aac-related pending? [12:37:26] <DonDiego> http://fate.multimedia.cx/index-v3.php [12:37:39] <mru> right now one of the tests is failing on all big endian machines [12:37:43] <peloverde> DonDiego, nope [12:37:46] <siretart> hm. make: *** [regtest-mxf] Error 1 - on linux x86 [12:37:57] <mru> compiler? [12:38:11] <DonDiego> ouch [12:38:21] <DonDiego> mru: can you fix it? :) [12:38:25] <peloverde> Once the branch is made I will run conformance again, but after the last AAC related commit it was passing [12:38:36] <mru> DonDiego: I don't know what's wrong [12:38:42] <mru> but it looks like something swscale related [12:38:51] <mru> if you can fix that, I'll buy a beer [12:39:00] <DonDiego> just one? [12:39:01] <DonDiego> ;) [12:39:13] <mru> for that, you can have two [12:39:15] <DonDiego> if somebody can localize the failing revision.. [12:39:47] <DonDiego> also, i'm supposed to bisect a regression right now [12:39:56] <siretart> well, TBH, this x86_32 / Linux / gcc svn 156187 (built 2010-01-22) looks like the only one I'd worry about remotely. The other fate regressions don't look like they're going to hit any debian architecture [12:40:01] <DonDiego> but on hipl (work), not ffmpeg.. [12:40:17] <mru> did debian drop all big endian? [12:40:17] <superdump> Dark_Shikari: i don't suppose you know of any algorithms that would be suited to identifying images that make use of digital zoom would you? [12:45:06] <Kovensky> debian still works on ppc no? isn't ppc wrong-endian? [12:45:39] <pengvado> superdump: fft? [12:45:57] <peloverde> Dark_Shikari, do you know of any simple video editing software (ala Windows Movie Maker) for Windows that can export with x264? [12:49:17] <siretart> Kovensky: you're right, I missed that line. seems the test 'mtv' is broken on powerpc: http://fate.multimedia.cx/index.php?test_result=54717668 [12:49:38] <mru> yes, that test fails on all big endian [12:49:50] <siretart> is that intended or a bug? [12:49:59] <mru> of course it's a bug [12:50:16] <mru> we're not in the intentional breakage business [12:50:24] <siretart> and how severe is it? what's exactly broken? [12:50:44] <mru> I know only what the error message says [12:51:03] <siretart> swScaler: rgb565le is not supported as input pixel format [12:51:05] <siretart> hm [12:56:35] <Quentar> Greetings, is there and option for ffmpeg to write PID file ? if not, would a patch be welcomed ? [12:57:29] <av500> what for? [12:58:07] * Kovensky wonders if libswscale still doesn't work on win64 [12:58:18] <kierank> Quentar: PID file? [12:58:43] <Quentar> kierank: file with process id , I am trying to automate some streaming services using ffmpeg and pidfile would help greatly . [12:58:44] <av500> ps | grep ffmpeg? [12:58:51] <Kovensky> Quentar: ffmpeg $PARAMS & echo $! > /var/run/ffmpeg.pid && wait %% [12:58:55] <kierank> oh that kind of PID [12:59:21] <Kovensky> well, the wait is optional :> [13:00:55] <Quentar> oh, thanks, I don't like bash that much, but I cannot definitely grep them cause there is a bunch of them running [13:03:12] <BastyCDGS> one small question regarding AVFormatContext::duration [13:03:34] <BastyCDGS> docs say in AV_TIME_BASE [13:04:06] <elenril> Quentar: you should ask this kind of questions in #ffmpeg [13:04:08] <mru> btw, pid files are inherently unsafe [13:04:08] <BastyCDGS> the thing is that each frame is always 1/60th a second in IFF ANIM [13:04:32] <BastyCDGS> can i just do a: s->duration += AV_TIME_BASE; [13:04:41] <BastyCDGS> and at the end divide it by 1/60th at a second [13:04:56] <BastyCDGS> for each FORM...ILBM chunk in IFF-ANIM (it's one frame) [13:05:01] <Quentar> elenril: ok, I am sorry, but I also wanted to know if the patch for such a small thing would be ok/worth it [13:05:51] <BastyCDGS> hey BBB how are u? [13:06:26] <BBB> howdy [13:06:30] * BBB needs coffee [13:06:54] * BastyCDGS teleports a cup of coffee to BBB [13:07:15] <BBB> I'll make some actual fresh :) [13:07:16] <BBB> hi jai [13:07:23] <BastyCDGS> heyho jai [13:07:32] <av500> jai: how do I access the 1772 sample file? [13:09:52] <BastyCDGS> jai or BBB, i have a small problem with setting duration... [13:09:59] <BastyCDGS> I'm not clear about AV_TIME_BASE [13:10:05] <Kovensky> also, I now know why my repo.or.cz link wasn't working [13:10:09] <Kovensky> whoever made that repo on repo.or.cz typoed the project's name [13:10:12] <BastyCDGS> in IFF-ANIM a frame is always 1/60th a second [13:10:16] <Kovensky> and called it FFMpeg-mirror :V [13:10:35] <BastyCDGS> just coding that for each FORM...ILBM chunk i add AV_TIME_BASE... [13:10:41] <BastyCDGS> and at the end I want divide by 1/60th second [13:11:15] <BastyCDGS> #define AV_TIME_BASE 1000000 [13:11:23] <BastyCDGS> this is 1 microsecond, right? [13:13:31] <Kovensky> forgot the name [13:13:40] <Kovensky> but it's 1/1000000th of a second :> [13:14:30] <bilboed> microsecond [13:14:58] * elenril throws http://en.wikipedia.org/wiki/SI_prefix at Kovensky [13:15:39] <BastyCDGS> for each frame i did a: s->duration += AV_TIME_BASE; [13:15:45] <BastyCDGS> at the end s->duration /= 60; [13:15:48] <BastyCDGS> should be fine then... [13:20:27] <merbanan> bbl, of to the boat [13:22:17] <Kovensky> time base math is weird :( [13:23:15] <av500> but its a good excuse when you are late... :) [13:23:28] <av500> ---sorry, wrong timebase... [13:24:48] <BastyCDGS> ;) [13:25:15] <BastyCDGS> well I've finished most of the chunk reading stuff [13:26:43] <BBB> huh? [13:26:49] <BBB> why do you want to set duration? [13:26:55] <BBB> our iff demuxer does that already [13:27:02] <BBB> you only should decode iff frames [13:28:49] <BBB> oh, spyfeng, good timing ;) [13:28:54] <BBB> we sent the same msg at the same time ;) [13:31:12] <BastyCDGS> don't see a line where it sets the duration... [13:32:04] <BastyCDGS> the iff decoder in libavformat (that's what I'm editing right now) doesn't handle IFF-ANIM [13:32:15] <BastyCDGS> since it simply skips the FORM-ILBM chunks inside [13:32:32] <peloverde> BBB, what's the status of ffmtech.org? [13:32:53] <BBB> we're looking for a volunteer to write the website :( [13:32:57] <BastyCDGS> i have added: [13:32:59] <BastyCDGS> if ( AV_RL32(d) == ID_FORM && [13:32:59] <BastyCDGS> (AV_RL32(d+8) == ID_8SVX || AV_RL32(d+8) == ID_PBM || AV_RL32(d+8) == ID_ILBM || AV_RL32(d+8) == ID_ANIM) ) [13:33:11] <BastyCDGS> in static int iff_probe(AVProbeData *p) [13:33:17] <BastyCDGS> so it recognizes IFF-ANIM [13:33:30] <BastyCDGS> now I'm dealing with iff_read_header [13:33:41] <BastyCDGS> i guess this func is called on very first read only [13:33:51] <BBB> yes [13:34:00] <BBB> probe is to see the type of file you're dealing with [13:34:02] <BBB> mp3? avi? etc. [13:34:13] <BBB> in this case, you're probing to see whether the file is iff [13:35:07] <BastyCDGS> that's clear i already added the ID_ANIM stuff [13:35:10] <BastyCDGS> as you see ;) [13:35:14] <BastyCDGS> that isn't the problem [13:36:09] <BastyCDGS> but i don't see a line in the iff stuff which does any duration calculation [13:36:28] <BBB> I think many "game" demuxers don't do stuff like that, or seeking [13:36:33] <BBB> it's more or less just a means to transcode it [13:36:43] <BBB> I'd focus on decoding first, in libacodec/iff.c [13:39:03] <BastyCDGS> do you think i should do a dryrun with the make test codec command after adding the codec? [13:39:10] <BastyCDGS> with the stub decoder and then go on? [13:40:01] <BBB> if you think it might break things, yes [13:40:05] <BBB> but I don't think it'll break things [13:40:09] <Kovensky> <+av500> but its a good excuse when you are late... :) <+av500> ---sorry, wrong timebase... <-- I wish my professors even knew what a timebase was :P [13:40:15] <Kovensky> maybe the more math inclined ones might now, but... [13:40:21] <BBB> BastyCDGS: just make sure it reads the proper chunks in the iff demuxer [13:40:24] <BBB> then move on to the decoder [13:40:25] * Kovensky is always late anyway :( [13:40:30] <BBB> don't bother with timestamps too much for now [13:40:33] <BBB> we can do that later [13:40:37] <BBB> the task is to write the decoder ;) [13:42:31] <Kovensky> yeah, timestamps... [13:42:47] <Kovensky> I'll have some chatting to do later today about timestamp handling between demuxer and decoder :v [13:44:52] <BastyCDGS> then it's probably the best way to simply check at the beginning in libavformat/iff.c if it's IFF-ANIM and then jump straight into the first FORM...ILBM sub chunk [13:45:06] <BastyCDGS> and just add the new chunks [13:45:11] <BastyCDGS> and go on to the demuxer [13:45:25] <BastyCDGS> well that sounds a lot more easier than the approach I did for now [13:45:32] <BBB> too complex, don't "jump", simply follow the existing structure of the demuxer [13:45:40] <BBB> it already reads iff files [13:45:44] <BBB> make it recognize iff/anim [13:45:54] <BBB> then go into iff_read_packet() (I think that's what it's called) [13:46:05] <BBB> change that function so it recognizes anim chunks, whatever they're called [13:46:12] <BBB> and hand them to the demuxer [13:46:19] <BBB> in iff_read_header(),set the correct CODEC_ID_ [13:46:23] <BBB> for the video stream [13:46:27] <BBB> and that's all you need to do [13:48:57] <BastyCDGS> investigating the code, it can't handle recursive IFF chunks [13:49:28] <jai> hey there BBB [13:49:28] <BastyCDGS> the structure of IFF ANIM contains a sub-FORM chunk [13:49:54] <jai> av500: do you have access to incoming.mphq? [13:50:12] <BBB> BastyCDGS: ok, so then try to make minimal changes so it handles recursive chunks for iff/anim [13:50:22] <BBB> BastyCDGS: but don't "rewrite" the whole demuxer, that's generally not necessary [13:50:24] <BBB> make small changes [13:50:27] <av500> jai: I dont think so [13:53:21] <BastyCDGS> i will make it recognize sub-FORM chunks and put a while into it that should to it [13:53:37] <BastyCDGS> although I'd copy some of the code [13:55:03] <BastyCDGS> av_get_packet(pb, pkt, iff->body_size); [13:55:08] <BastyCDGS> does this call the demuxer? [13:55:37] <BBB> no [13:55:44] <BBB> you are in the demuxer now [13:55:49] <BBB> libavformat/iff.c is the demuxer [13:55:56] <BBB> it creates a packet to put the data in [13:56:06] <BBB> and then reads the data into i [13:56:07] <BBB> t [13:57:33] <BastyCDGS> sorry meant does this call the decoder [14:01:51] <jai> av500: http://www.mediafire.com/?gmyhlfttmj2 [14:02:45] <BastyCDGS> i think that could do the trick (note the missing break): [14:02:49] <BastyCDGS> case ID_FORM: [14:02:49] <BastyCDGS> chunk_id = get_le32(pb); [14:02:49] <BastyCDGS> data_size = get_be32(pb); [14:02:49] <BastyCDGS> padding = data_size & 1; [14:03:30] <BastyCDGS> it will ensure that reaching the default will not skip over the whole sub FORM-chunk but just the first entry of the sub-chunk [14:04:12] <BastyCDGS> is that small enough? ;) [14:06:02] <av500> jai: thx [14:10:04] <DonDiego> mru: i have a commit pending for which you will love me so much that you really should consider looking into that mtv regression on big-endian [14:10:06] <BBB> BastyCDGS: does it work? I like it - btw add a comment that it is a list-schunk then [14:10:07] <DonDiego> :) [14:10:18] <DonDiego> just give me a few more minutes.. [14:10:41] <BastyCDGS> I'm just adding the remaining chunks... [14:10:45] <BastyCDGS> one moment plz [14:11:01] <BastyCDGS> i think i have now understand the concept of your iff decoder [14:11:16] <BastyCDGS> it's a very unusual approach but very clever [14:12:55] <BBB> DonDiego: can you do the blind qcelp listening? [14:13:02] <BBB> dondiego: I want to apply that patch badly [14:13:08] <BBB> it blocks +/- 6 other patches in my tree [14:13:18] <BBB> (little unfortunate ordering) [14:13:42] <DonDiego> right now is not a good moment, i'm already misusing some work time for ffmpeg ;) [14:13:59] <mru> what's your change about? [14:14:28] <DonDiego> let's maintain the suspense [14:14:39] <mru> vp8 decoder? [14:14:43] <DonDiego> it's something you've always hated.. [14:14:47] <DonDiego> lol [14:14:53] <DonDiego> no, it's small but neat [14:14:58] <DonDiego> you will like it, promised [14:17:02] <BBB> he's asking for a wildcard [14:17:07] <BBB> I'm sure it's something pkg-config related [14:17:13] <BBB> I'd better get my popcorn [14:21:07] <DonDiego> nope, not pkg-config [14:23:54] <CIA-7> ffmpeg: diego * r22919 /trunk/libavcodec/libtheoraenc.c: cosmetics: Switch Doxygen comments to JavaDoc style. [14:24:51] <BastyCDGS> what do yout think about using the avi demuxer as base for iff? [14:25:05] <BastyCDGS> after all IFF is the same as RIFF just IFF is big endian and word aligned [14:25:53] <BastyCDGS> not want to do this yet, but as a general idea [14:26:01] <BastyCDGS> it looks to me the RIFF code base is cleaner [14:29:49] <Tjoppen> does IFF have the same peculiar handling of odd-length atoms as RIFF/AVI? [14:30:46] <BastyCDGS> if the chunk size is odd in IFF one byte is skipped in the IFF file (so each chunks starts on 2 byte boundary) [14:30:48] <Tjoppen> according to wikipedia: yes [14:31:09] <BastyCDGS> reason for this is that old plain 68000 can only do word/dword access on even addresses [14:31:25] <BastyCDGS> so you can read a whole IFF file straight into memory and don't have to deal with such issues [14:31:40] <Tjoppen> sounds like how quake handles model and map loading :o [14:33:06] <Tjoppen> well, refactoring them to share code doesn't sound too bad. reading the AVI demuxer a while back it looked like it might be possible to get it out of alignment with some strategically placed odd-length atoms (there's a hack in there for just such a case) [14:33:16] <scaphilo> anyone knows whats the problem with long motion vectors when restricted motion vectors are not allowed? [14:33:32] <scaphilo> i copy the motion vectors from mpeg2 to mpeg4 [14:33:41] <scaphilo> there must be a difference i dont understand [14:36:19] <Tjoppen> ah, there it is. avidec.c:563: if (size%2) /* 2-aligned (fix for Stargate SG-1 - 3x18 - Shades of Grey.avi) */ [14:37:43] <DonDiego> hmm [14:37:44] <DonDiego> libavformat/dvenc.c:82: warning: implicit declaration of function ‘brktimegm’ [14:38:19] <BastyCDGS> wouldn't if (size&1) be better? ;) [14:39:19] <BBB> probably [14:39:38] <BBB> BastyCDGS: send a patch, it'll be accepted [14:39:45] <BBB> although most likely the compiler does it right already [14:40:12] <BastyCDGS> ok, one moment... [14:41:11] <BastyCDGS> the compiler does this only for unsigned if i'm not wrong since mod differs from and in that case [14:41:30] <BBB> that's / [14:41:34] <BBB> for %, it's the same [14:42:44] <CIA-7> ffmpeg: diego * r22920 /trunk/libavformat/dvenc.c: [14:42:44] <CIA-7> ffmpeg: Add missing internal.h #include for brktimegm(), fixes the warning: [14:42:44] <CIA-7> ffmpeg: libavformat/dvenc.c:82: warning: implicit declaration of function ?brktimegm? [14:43:18] <BastyCDGS> can I merge the size&1 patch with the basic IFF-ANIM demuxer/decoder registration? [14:44:08] <DonDiego> 480 files changed :) [14:44:08] <Tjoppen> most likely: no [14:44:18] <BBB> holy shit [14:44:23] <BBB> BastyCDGS: no [14:44:49] <BBB> DonDiego: if your patch screws up my patches, I will so kill you [14:45:05] <BastyCDGS> btw, shall I fix the comment, too? [14:45:09] <DonDiego> haha [14:45:14] <BBB> BastyCDGS: if you wish [14:45:20] <BastyCDGS> a concrete avi file in here? [14:45:22] <DonDiego> wow, this is taking long to go through.. [14:45:44] <BBB> BastyCDGS: I'd leave the comment alone [14:45:49] <BBB> just fix the % -> & [14:45:57] <BastyCDGS> ok then I'll post it to ml now [14:46:07] <Tjoppen> if you were to change it, I'd say provide better documentation [14:46:23] <av500> "Remove explicit filename from Doxygen @file commands." [14:46:54] <CIA-7> ffmpeg: diego * r22921 /trunk/ (479 files in 11 dirs): [14:46:54] <CIA-7> ffmpeg: Remove explicit filename from Doxygen @file commands. [14:46:54] <CIA-7> ffmpeg: Passing an explicit filename to this command is only necessary if the [14:46:54] <CIA-7> ffmpeg: documentation in the @file block refers to a file different from the [14:46:55] <CIA-7> ffmpeg: one the block resides in. [14:48:25] <DonDiego> mru: so? :) [14:48:41] * BBB grabs popcorn just in case [14:49:03] <mru> that was it? [14:49:17] * mru neither reads nor writes documentation [14:49:23] <DonDiego> bah [14:49:35] <DonDiego> you've complained about this time and again! [14:49:48] <mru> I'm mentioned it once or twice [14:50:07] <BastyCDGS> patch commited to mailing list [14:51:01] * av500 expected spaces to tabs conversion... [14:51:01] * DonDiego is disappointed [14:51:04] <DonDiego> bah [14:51:33] <jai> BastyCDGS: don't compilers do that already [14:52:24] <BastyCDGS> I'm not sure they do this with modulo when data type is signed [14:52:29] <BBB> DonDiego: will you now do my blind qcelp listening test? [14:52:50] <BastyCDGS> or with -O0 [14:53:26] <DonDiego> BBB: sorry, now i need to do a bit of the work i get paid for .. [14:53:35] <BBB> who needs pay anyway? [14:54:10] <jai> BastyCDGS: size should be unsigned in this case, if it isn't then that should be fixed [14:54:44] <jai> BastyCDGS: also, unless you are debugging you probably shouldn't be using -O0 :) [14:56:04] <BastyCDGS> ahh good that you're mentioning it [14:56:13] <BastyCDGS> it's declared as unsigned int !!! [14:56:17] <BastyCDGS> should be uint32_t [14:56:19] <BastyCDGS> or? [14:56:29] <BastyCDGS> just do another patch one moment... [14:56:50] <jai> why uint32_t? [14:57:02] <BastyCDGS> because int can be 16 bits or 64 bits [14:57:07] <BastyCDGS> but avi size is always 32 bit [14:57:17] <BastyCDGS> causes unneccesary conversions on 64 bit architectures [14:57:22] <jai> we dont support 16bit arches :) [14:57:33] <BastyCDGS> same to: [14:57:36] <BastyCDGS> unsigned int tag, tag1, handler; [14:57:40] <BastyCDGS> i saw a: [14:57:53] <BastyCDGS> tag1 = get_le32(pb); [14:59:06] <jai> meh, bbiab [14:59:21] <BastyCDGS> may I fix that? [15:00:37] <BastyCDGS> changed to: [15:00:39] <BastyCDGS> uint32_t tag, tag1, handler; [15:00:47] <BastyCDGS> all 3 are read with get_le32(pb) [15:03:38] <BastyCDGS> hmm looking around in the same function shows me it's mostly used in conjunction with uint64_t [15:08:51] <BBB> BastyCDGS: unsigned int is fine, it's in fact faster on some systems than uint32_t [15:08:56] <BBB> so please leave it as unsigned int [15:09:03] <BBB> these patches are generally not accepted [15:09:09] <BastyCDGS> ok [15:09:28] <BBB> we want it to be 64-bit on systems where it's that, because then math is faster [15:16:49] <astrange> what systems do we support with 64-bit int? [15:17:02] <mru> none [15:17:34] <mru> but the basic types should still be used where the exact size doesn't matter [15:19:48] <BBB> peloverde: do you have some time for my blind qcelp listening test? [15:20:18] <peloverde> my ears are pretty crappy [15:20:32] <BBB> you're our in-house audio expert! they surely are better than mine [15:20:48] <BastyCDGS> better don't ask me about my ears ;) [15:20:56] <peloverde> There are pre-echo artifacts that are deemed severe that I cannot hear [15:21:09] <peloverde> and anyway I need to finish PS before I go to Florida on Thursday [15:21:15] <BBB> ok ok :) [15:22:34] <astrange> i can do an abx now if you don't mind ipod earbuds [15:22:53] <kierank> BBB: I can try if you want as well [15:27:02] <DonDiego> BBB: ping me about the listening test later [15:35:29] <BastyCDGS> so just compiling to see if it works now [15:41:13] <BBB> dondiego: ok [15:41:15] <BBB> oops, he's gone [15:41:28] <BBB> kierank: that'd be great, did you see the email on-list? [15:42:01] <BBB> http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/107976 [15:42:03] <BBB> see that email [15:50:21] <BastyCDGS> just running make test, hope it works [15:52:43] <BastyCDGS> could someone explain me how the tests actually work I mean i'm wondering how the codecs do verify themself and what files they use [15:52:51] <BastyCDGS> have I prepare some IFF-ANIM files for testing? [15:53:20] <Compn> which test ? [15:53:25] <Compn> oh make test [15:53:33] <Compn> you can read makefile to see what it does [15:53:40] <astrange> can't distinguish r1.wav / r2.wav (p = .75) [15:56:07] <BastyCDGS> make test is already running just want to know if I have to setup a test for a new codec manually (providing IFF-ANIM files etc.) [15:57:45] <BastyCDGS> the tests went successfully itself after applying my code but didn't see a test for iff [15:59:39] <astrange> BBB: i can't tell the difference between any of them in a mildly noisy environment [16:00:01] <kierank> I can't tell any difference either [16:00:13] <kierank> possibly r3 is every so slightly better [16:02:43] <Dark_Shikari> bilboed: I know the celt guys use it sometimes [16:03:02] <Dark_Shikari> peloverde: dunno [16:03:04] <bilboed> Dark_Shikari, ok, I'll ask derf [16:10:33] <BastyCDGS> just sent a RFC of my patch to mailing list [16:10:44] <BastyCDGS> could someone take a look and give me some advice based on this? [16:15:10] <BastyCDGS> hey dark shikari, how are u? [16:16:04] * mru glares at Dark_Shikari [16:16:10] <mru> BastyCDGS: he's frightened :-) [16:18:28] <BastyCDGS> or just busy ;) [16:19:57] <BastyCDGS> mru, could you review my rfc patch? [16:23:18] <BastyCDGS> when I try to play an IFF-ANIM [16:23:33] <BastyCDGS> it says: [16:23:36] <BastyCDGS> [IFF @ 0x8b2f790]iff: unknown compression method [16:23:57] <BastyCDGS> so the file is detected correctly [16:24:18] <BastyCDGS> ./ffplay ../../ffmpeg-svn.orig/patches/anim-j/BoingThrows/BoingThrows [16:24:22] <BastyCDGS> that was my cmd line [16:25:00] <BastyCDGS> but it doesn't out the stub debug info [16:25:38] <BastyCDGS> is that because libavformat doesn't forward to libavcodec on cases like unknown compression? [16:28:05] <BastyCDGS> oh I forget one line, after: [16:28:24] <BastyCDGS> the unknown compression method, it says: ../../ffmpeg-svn.orig/patches/anim-j/BoingThrows/BoingThrows: Operation not permitted [16:30:31] <BBB> uh... [16:30:36] <BBB> astrange: what do these mplayer commandlines do? [16:36:34] <BastyCDGS> damn I've forgotten the compression methods in the cases [16:43:12] <BastyCDGS> thanks for reviewing... [16:43:27] <BastyCDGS> will fix now the stuff you've been complaining [16:52:25] <jai> elenril: ping [16:52:28] <BastyCDGS> mru the iff.h file was just a naive C++ class to C conversion that's why it looks strange [16:52:38] <BastyCDGS> made protected methods static funcs [16:52:42] <BastyCDGS> and public normal [16:54:09] <astrange> BBB: plays the first 3 seconds of the file [16:54:30] <astrange> with abxtest from madplay [16:56:05] <BastyCDGS> mru, i changed my typedef you've been complaining to following, ok? [16:56:07] <BastyCDGS> typedef enum {ANIM_LONG_DELTA, ANIM_SHORT_DELTA, [16:56:07] <BastyCDGS> ANIM_GENERAL_DELTA, ANIM_BYTE_VERTICAL_DELTA, ANIM_STEREO_BYTE_DELTA, [16:56:07] <BastyCDGS> ANIM_BYTE_VERTICAL_DELTA_WORD, ANIM_BYTE_VERTICAL_DELTA_LONG, [16:56:07] <BastyCDGS> ANIM_ERIC_GRAHAM = 74} anim_compression_type; [16:57:20] <mru> one name per line, please [16:57:27] <mru> like everywhere else [16:57:35] <mru> the two enums above it are the ugly exceptions [17:02:05] <elenril> jai: pong [17:03:06] <BastyCDGS> ok then I'll change the two enums, too... [17:03:45] <jai> elenril: hi, quick question : why does the txxx frame parsing code have a 512 byte limit? [17:03:46] <mru> not in the same patch [17:05:50] <BastyCDGS> ok, is it okay when I change the two enums and the indentiation in one patch? [17:05:55] <CIA-7> ffmpeg: rbultje * r22922 /trunk/libavformat/avidec.c: Change a %2 to &1. Patch by Sebastian Vater <cdgs DOT basty googlemail com>. [17:06:27] <BastyCDGS> merci [17:06:59] <BBB> welcome [17:07:02] <elenril> jai: dunno [17:07:07] <BBB> or, well, since you're belgian [17:07:08] <BBB> de rien [17:07:15] <elenril> probably because whoever wrote it thought it was enough for everyone ;) [17:08:20] <BastyCDGS> i thought 640KB are enough for everyone :D [17:08:26] <jai> elenril: well, we would need to be able to parse variable length strings [17:08:51] <jai> elenril: though at this point i'm not sure which would be the cleaner way of doing this [17:09:01] <elenril> yeah, i guess yuo'd need that for long things like lyrics [17:09:10] <jai> elenril: exactly :) [17:09:13] <elenril> malloc(len);? [17:09:25] <jai> also i all these miley cyrus lyrics are BS [17:09:26] <jai> but whatever [17:09:32] <jai> -i [17:09:55] <jai> elenril: theoretically length could be 32 bits [17:15:27] <BBB> more people interested in blind qcelp audio quality test? [17:15:32] <BBB> kierank: did you test? [17:15:46] <kierank> yes [17:15:51] <kierank> couldn't hear any difference [17:16:03] <BBB> ok [17:16:15] <BBB> astrange: can you add mplayer -endpos 3 r[23].wav? [17:16:19] <BBB> just so we have a complete list [17:17:37] <astrange> if 1==2 and and 1==3 then 2==3 [17:17:39] <astrange> i think [17:17:57] <BBB> I want the percentages and differences [17:21:01] <astrange> um, i went faster and got more accurate results than last time, how'd that happen [17:21:05] <astrange> still wasn't significant though [17:21:05] <astrange> correct: 7/10 (70%) [17:21:05] <astrange> probability (p) of result being the same as random guesses = .1718742 [17:21:10] <BastyCDGS> bbb french is not my native language...it's german, but since I'm now living in french spoken part of be I changed my ubuntu to fr-BE locale [17:21:25] <BastyCDGS> so i learn it faster and on-the-fly ;) [17:25:13] <BastyCDGS> indent patch commited to ml [17:27:48] <BBB> astrange: I still don't know what it tests :) [17:28:24] <BBB> ah, I see from wikipedia now [17:28:26] <BBB> ingenious [17:29:07] <astrange> needs to be p = .05 (95% accurate) [17:29:18] <BBB> right [17:29:49] <BBB> ok, I'll take that as random then [17:31:35] <BBB> BastyCDGS: look at enum codecID in avcodec.h to see how to declare enums [17:31:39] <jai> BastyCDGS: could you avoid the cosmetics stuff [17:31:43] <BBB> the second part of the patch is ok [17:31:55] <BBB> jai: his patch = cosmetics :) [17:32:08] <BBB> typedef enum {\n [17:32:18] <BBB> space space space space COMP_NONE,\n [17:32:21] <BBB> etc. [17:32:22] <BBB> }; [17:32:39] <BBB> actually, make that } bla_type; [17:34:13] <BastyCDGS> so drop the typedef in front too? [17:34:38] <BastyCDGS> ah ok I see indent is 4 [17:35:34] <BBB> don't drop the typdef, then it wouldn't compile [17:35:59] <jai> BBB: yeah, what's the point :) [17:36:03] <BastyCDGS> but bitmap_compression_type etc.? [17:36:44] <jai> ease of maintenance is probably the only consideration here [17:38:03] <CIA-7> ffmpeg: rbultje * r22923 /trunk/ (doc/ffmpeg-doc.texi ffmpeg.c): [17:38:03] <CIA-7> ffmpeg: Allow setting the environment variable FFMPEG_DATADIR to locate preset files. [17:38:03] <CIA-7> ffmpeg: Patch by Robert Kr?ger <krueger signal7 de>. [17:38:18] <BBB> hmm... [17:39:17] <jai> i'd suggest sticking to just functionality related code right now [17:39:51] <BBB> I don't mind such fixes [17:40:00] <BBB> but yes, make sure you finish some iff/anim-related code also ;) [17:41:08] <BastyCDGS> i'm debugging iff-anim stuff right now [17:41:19] <BastyCDGS> the 3rd chunk being read is complete null [17:42:00] * BBB goes for lunch [17:42:15] <BastyCDGS> bon appetit :) [17:45:56] <BastyCDGS> fixed indent patch commited to ml [17:49:38] <BastyCDGS> serious problem [17:49:49] <BastyCDGS> the existing code is broken [17:50:12] <BastyCDGS> reading BMHD [17:51:02] <BastyCDGS> using the same code with an IFF-ANIM doesn't work on reading BMHD [17:51:21] <BastyCDGS> [IFF @ 0x8b2f790]iff: reading chunk 0x4d524f46, size: 0x0000a736 [17:51:21] <BastyCDGS> [IFF @ 0x8b2f790]iff: reading chunk 0x44484d42, size: 0x00000014 [17:51:21] <BastyCDGS> [IFF @ 0x8b2f790]iff: reading chunk 0x0000474d, size: 0x00040000 [17:51:21] <BastyCDGS> [IFF @ 0x8b2f790]iff: reading chunk 0x00000000, size: 0x00000000 [17:51:21] <BastyCDGS> [IFF @ 0x8b2f790]iff: unknown compression method [17:51:28] <BastyCDGS> (added this for debug) [17:51:39] <BastyCDGS> 0x44484d42 is BMHD [17:52:25] <BastyCDGS> iff-anim hexdump of first 4 lines: [17:52:30] <BastyCDGS> 00000000 46 4f 52 4d 00 03 0d 38 41 4e 49 4d 46 4f 52 4d |FORM...8ANIMFORM| [17:52:30] <BastyCDGS> 00000010 00 00 a7 36 49 4c 42 4d 42 4d 48 44 00 00 00 14 |...6ILBMBMHD....| [17:52:30] <BastyCDGS> 00000020 01 40 00 c8 00 00 00 00 06 00 01 00 00 00 0a 0b |.@..............| [17:52:30] <BastyCDGS> 00000030 01 40 00 c8 43 41 4d 47 00 00 00 04 00 00 48 00 |.@..CAMG......H.| [17:52:44] <BastyCDGS> that's the file it was trying to read [17:53:04] <BastyCDGS> after all the iff reading code is not standard conform at all [17:53:23] <BastyCDGS> because it expects the known chunks to be a specific size [17:53:54] <BastyCDGS> that's the first problem, the second problem is that the existing code assumes wrongly that BODY is the last chunk (while breaks then) [17:54:23] <BastyCDGS> although almost all IFF files follow the latter rule the IFF standard doesn't require this [17:56:53] <BastyCDGS> I'll create a separate patch now for making the old IFF code standard comforming, ok? [18:00:01] <BastyCDGS> it doesn't even check if a known chunk is large enough to hold the data it wants to read [18:11:23] <BBB> BastyCDGS: that sounds like a good idea, yes, if there's size elements that we don't conform to, then you want to fix this [18:11:35] <BastyCDGS> just doing it ;) [18:11:38] <BastyCDGS> VHDR already fixed [18:11:39] <BBB> great [18:11:41] <BBB> keep it going [18:12:08] <BastyCDGS> sorry I could have noticed this earlier...just have forgotten this after such a long time [18:12:28] <BastyCDGS> (I was considering that when loading TuComposer Module which does it right) [18:14:51] <BastyCDGS> in ANNO stuff there the padding skip is completely missing [18:15:09] <BastyCDGS> so your original code breaks on any IFF file which has an odd annotation string length [18:23:05] <BBB> feel free to add padding skips where you feel it's necessary [18:24:33] <BastyCDGS> finished all chunks [18:24:39] <BastyCDGS> just checking if it compiles [18:26:43] <BastyCDGS> yes it does ;) [18:28:33] <BastyCDGS> can i merge that patch with the indent stuff? [18:29:37] <BastyCDGS> if not it would be good if someone at least commits that to svn since the diff I got doesn't delimit both [18:31:48] <BBB> use git, or quilt [18:32:03] <elenril> git++ [18:32:24] <kierank> git# [18:32:27] <kierank> or objective git [18:32:39] <BastyCDGS> I have no experience with git yet... [18:33:45] <BBB> what was the way to check for non-whitespace changes again? [18:33:54] <BBB> svn diff -xyz or so? [18:34:02] <janneg> -x b [18:34:10] <janneg> or -x w [18:35:00] <janneg> maybe -x -b|w [18:36:22] <BastyCDGS> -x b doesn't work with svn diff [18:36:27] <BastyCDGS> neither does -x w [18:36:52] <BBB> well I applied it anyway [18:37:00] <BBB> svn up to continue [18:37:10] <BBB> and become a git master, it's useful [18:39:01] <BastyCDGS> not yet arrived here...do i have to wait until CIA-7 says it here? [18:40:43] <BastyCDGS> ok is here [18:41:04] <BastyCDGS> but the typedef enum stuff? [18:41:14] <kierank> does anyone else keep thinking of turkey basters when reading BastyCDGS's comments? [18:41:25] <BBB> I committed it all [18:41:37] <CIA-7> ffmpeg: rbultje * r22924 /trunk/libavformat/iff.c: [18:41:37] <CIA-7> ffmpeg: Reindent / reformat some code with broken indenting. [18:41:37] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs DOT basty googlemail com>. [18:42:02] <BastyCDGS> kierank which comments you mean exactly? [18:42:22] <kierank> your username [18:42:58] <BastyCDGS> CDGS = Coders Develop Glorious Stuff ;) [18:43:15] <BBB> I always thought we were hackers, not coders [18:48:58] <BastyCDGS> #define HACKER CODER :P [18:52:14] <drv> is there any way to filter the bug tracker to show only non-license-violation bugs? [18:52:34] <BastyCDGS> patch commited for 100% IFF standard compliance [18:52:37] <BastyCDGS> at ml [18:54:08] <elenril> 110% when [18:55:03] <drv> when the marketing department arrives ;) [18:59:08] <BBB> drv: uh, they have their own bug status [18:59:14] <BBB> drv: so select all other bug statuses [18:59:17] <BBB> then click search [18:59:23] <jai> drv: license violation related issues are piling up like crazy [18:59:33] <jai> time to let the lawyers loose? :) [18:59:53] <drv> well, they have their own topic, but you can only search by one topic at a time, unless there's another search page i'm missing [19:00:01] <BBB> rly? [19:00:11] <drv> looking at https://roundup.ffmpeg.org/issue?@template=search [19:00:19] <jai> roundup's interface is a pos imho [19:00:36] <drv> it's rather slow too, or maybe that's just because i'm on the other side of the ocean ;) [19:00:51] <kierank> it's slow anyway I think [19:00:52] <BastyCDGS> wtf??? i just read the mail I sent and the annotation stuff was still in? [19:01:03] <BastyCDGS> indentation sry [19:01:18] <BBB> drv: you're right [19:01:19] <BBB> that sucks [19:01:21] <BBB> file a bug :) [19:01:32] <BastyCDGS> will resent the patch, I probably did choose the wrong file (older one) [19:02:56] <BastyCDGS> done [19:03:04] <BBB> where are the iff samples on samples.mphq.hu? [19:03:23] <jai> BBB: btw, you are reviewing the iff stuff right? [19:03:29] <BBB> yes [19:03:34] <jai> nice :) [19:03:38] * jai goes to watch a movie [19:04:36] <BastyCDGS> which movie? [19:05:11] <_av500_> BBB? [19:05:26] <BBB> screw you :) [19:05:29] <BBB> ;) [19:05:58] <BBB> jai: but any help is appreciated [19:06:35] <BastyCDGS> just forgot to add the copyright note to the iff stuff, should I add this as a single patch? [19:09:29] <BBB> do it at the end [19:09:33] <BBB> is generally the recommended approach [19:09:43] <janneg> _av500_: ~4 scenes remaining, 3600 frames [19:28:42] <BBB> BastyCDGS: download http://samples.mplayerhq.hu/image-samples/ASH.LBM [19:28:50] <BBB> BastyCDGS: after your patch, make sure that frame still displays [19:28:54] <BBB> that's a good test [19:29:11] <BastyCDGS> I've made an error in the BODY chunk [19:29:15] <BastyCDGS> just fixing that [19:29:26] <BastyCDGS> was skipping one byte always without reading the body stuff [19:43:46] <BBB> make sure to test your changes [19:44:03] <BBB> this sort of stuff should generally not happen :) we expect you to check your changes if you can [19:50:50] <BastyCDGS> Input #0, IFF, from '../patches/ASH.LBM': [19:50:51] <BastyCDGS> Duration: N/A, bitrate: N/A [19:50:51] <BastyCDGS> Stream #0.0: Video: iff_byterun1, pal8, 320x240, PAR 5:6 DAR 10:9, 90k tbr, 90k tbn, 90k tbc [19:50:51] <BastyCDGS> 1271793003.07 A-V: 0.000 s:0.0 aq= 0KB vq= 0KB sq= 0B f=0/0 [19:50:58] <BastyCDGS> with my correction... [19:53:15] <BBB> but do you see the image? and is it identical? [19:54:40] <BastyCDGS> there is just this console output ;) [19:54:47] <BastyCDGS> no window with an image [19:55:09] <BBB> ok, remove your changes and try again - you should see a window pop up with an image [19:55:26] <BBB> good way to remove your changes: svn diff file > patch; svn revert file [19:55:41] <BBB> then figure out why [19:56:57] <mru> git does it better [19:57:12] <mru> "git stash" to hide away all your local changes [19:57:18] <mru> "git stash pop" to put them back [19:57:43] * BBB cries because he doesn't "get" git [19:58:29] <mru> think of it as something that does all the things you ever wished svn would and none of the things you wished it didn't [19:58:49] <BBB> I know... I just wish I knew how to use it [19:59:05] * mru wasn't born with that knowledge [19:59:29] <BBB> mru: can you do my blind qcelp listening test? [19:59:30] <BastyCDGS> do I have to set configure flags to get graphical output with ffplay under linux? [19:59:36] <BBB> BastyCDGS: no [19:59:38] <BastyCDGS> sth. like with-sdl? [19:59:49] <BBB> BastyCDGS: try any other video file [20:00:08] <BBB> you need sdl-devel though [20:00:17] <BBB> or whatever it's called on your distro [20:00:40] <BastyCDGS> video works [20:03:51] <BastyCDGS> what is exactly required for a window to be opened? [20:04:03] <BastyCDGS> i mean what the demuxer has to initialize for it? [20:05:28] <BBB> nothing, you broke the demuxer (I think) so it doesn't output any video packets [20:05:31] <BBB> then, no video window is shown [20:05:32] <BBB> :) [20:05:44] <BBB> so figure out what you broke and fix it [20:05:49] <BBB> e.g., remove your local changes [20:05:53] <BBB> then re-apply them one by one [20:05:55] <BBB> and see what breaks it [20:20:20] <BastyCDGS> removing done = 1 from the BODY part causes the trouble [20:20:49] <BBB> BastyCDGS: right, I can explain you why but maybe it's better if you figure it out yourself ;) it's a good lesson [20:20:58] <BBB> f you can't figure it out, let me know :-p [20:21:20] <BBB> I can also help suggest some fixes [20:21:42] <BastyCDGS> well I think I have it [20:21:51] <BastyCDGS> the file position has to be at the start at the chunk ;) [20:21:56] <BastyCDGS> BODY [20:22:04] <BastyCDGS> to the decoder can directly read it [20:22:24] <BastyCDGS> done ensures that it leaves the loop immediately [20:22:47] <BBB> not decoder, it's actually the demuxer itself [20:22:49] <BBB> but you're close [20:22:56] <BBB> you're looking at iff_read_header(), right? [20:23:06] <BastyCDGS> yes I'm looking there [20:23:40] <CIA-7> libswscale: diego * r31050 /trunk/libswscale/swscale.h: [20:23:41] <CIA-7> libswscale: Remove explicit filename from Doxygen @file commands. [20:23:41] <CIA-7> libswscale: Passing an explicit filename to this command is only necessary if the [20:23:41] <CIA-7> libswscale: documentation in the @file block refers to a file different from the [20:23:41] <CIA-7> libswscale: one the block resides in. [20:23:55] <BBB> ok, that's called once to open the file [20:24:04] <BBB> the actual data is transferred to the decoder in iff_read_packet() [20:24:06] <BBB> the next function [20:24:07] <BBB> look there [20:24:16] <BBB> your logic is correct, but this is all still part of the demuxer [20:24:18] <BastyCDGS> I just did ;) [20:24:23] <BBB> good, so continue there :0 [20:24:25] <BBB> :-p [20:24:36] <BastyCDGS> and seen that you read the buffer there [20:24:45] <BBB> the function looks crappy by the way [20:25:05] <BBB> "pkt" is the packet that will be sent to the demuxer at the end of this function call [20:25:14] <BBB> so the function is called repeatedly [20:25:18] <BBB> ocne per video frame [20:26:55] <BastyCDGS> ahhhhhhhhhhhhhhhhhhhhhhhhhhhhh [20:27:16] <BastyCDGS> so I have just to ftell to the BODY part? [20:27:25] <BastyCDGS> after leaving the IFF reading loop [20:27:40] <BastyCDGS> so the packet decoder reads the correct part [20:31:18] <BastyCDGS> what was me wondering when I remove the done=1 the start time isn't 0.0 but some "random" value [20:31:23] <BastyCDGS> why is this? [20:36:07] <BastyCDGS> yeah my patch works now [20:36:24] <BastyCDGS> just readded done and did a data_size_skip = 0 [20:36:34] <BastyCDGS> (renaming data_size_padding to data_size_skip sounds better) [20:40:28] <bcoudurier> hi guys [20:41:04] <BastyCDGS> hi bcoudurier [20:41:41] <Dark_Shikari> hi bcoudurier's onjoin script [20:42:09] <bcoudurier> :) [20:42:21] <bcoudurier> how do you do a good stereo to mono downmix ? [20:42:27] <Dark_Shikari> average the two channels? [20:43:45] <bcoudurier> is it the best ? [20:43:54] <bcoudurier> because it seems to me that it would lower the volume [20:44:16] <Dark_Shikari> you can't amplify it, that would cause clipping [20:44:24] <BastyCDGS> I do it by (left+right+1) >> 1; [20:44:30] <mru> that's average [20:44:35] <astrange> that's not the best way [20:44:37] <BastyCDGS> but with rounding up [20:44:52] <mru> arithmetic average doesn't conserve power [20:44:57] <astrange> the two channels could be opposite phase and it would sound different [20:44:58] <mru> or energy or something [20:45:10] <bcoudurier> indeed [20:45:15] <astrange> pretty much everything uses linear operations on audio [20:45:43] <mru> what is a good way to deal with phase shifts? [20:46:13] <astrange> not sure, i just know the problem exists and may not be worth dealing with in realtime [20:46:14] <bcoudurier> Yuvi, are you around ? [20:47:23] <mru> sound from two speakers also sounds differently depending on listening position [20:47:31] <mru> a single speaker always sounds the same [20:48:51] <BBB> you're suggesting to not convert to mono [20:48:54] <BastyCDGS> well you could cubic spline resampling [20:48:56] <BBB> but he wants to convert to mono :) [20:49:26] <BBB> what happens if you do the FFT, add these two up and IFFT it? [20:49:30] <BBB> I suppose you get garbage? [20:49:33] <mru> the ultimate mono downmix has to take listening position into account [20:49:49] <BBB> for mathematical simplicity, let's assume "center" [20:50:24] <mru> and a single ear? [20:50:46] <wbs> do a van gogh and chop one off :-) [20:51:01] <wbs> just for mathematical simplicity :-) [20:51:06] <BBB> BastyCDGS: yes, url_ftell() is a good way of solving it [20:51:10] <mru> oh, that's why he did it... [20:51:32] <BastyCDGS> lol [20:52:04] <BastyCDGS> and what's with the remaining one? do that to and you save the mono conversion completely... [20:52:09] <BastyCDGS> just stream /dev/zero :D [20:52:15] <BastyCDGS> faaaaaaaaaaast [20:52:36] <BastyCDGS> if that isn't mathematical simplicity I don't know...;) [20:58:02] <Dark_Shikari> mru: QOTD [20:58:04] <Dark_Shikari> "Ogg wasn't "designed", it was thrown together in the same fashion that a 4 year old cleans up his room by hiding all the toys in the closet. " [20:58:11] <BastyCDGS> I just updated the patch in ml [20:58:14] <mru> Dark_Shikari: lol [20:58:17] <BastyCDGS> this one is working now [20:58:25] <mru> Dark_Shikari: source? [20:58:35] <thresh> so you're friends again? [20:58:41] <Dark_Shikari> mru: a post on the internets [20:58:51] <BastyCDGS> thresh, looks like ;) [20:59:27] <mru> gotta love those internets [21:05:14] <BBB> http://forums.thedailywtf.com/forums/p/16477/220422.aspx [21:05:17] <BBB> gotta love google [21:05:22] <BBB> I seriously love google so much [21:05:27] <BBB> if I weren't married, I'd marry google [21:05:39] <Dark_Shikari> Yeah, I reposted it there [21:06:05] <Dark_Shikari> Good to know that the understanding of ogg's horribleness is widespread even outside of the video community ;) [21:06:51] <Dark_Shikari> oh by the way, mru, any conclusion on the pthread configure check? [21:08:26] <BBB> Dark_Shikari: can you do my blind qcelp audio test? [21:08:35] <Dark_Shikari> I can try, I don't have golden ears though [21:08:40] <Dark_Shikari> poke me in 20 minutes [21:08:43] <BBB> ok [21:09:34] <BastyCDGS> bbb, I got it working with ftell yeah [21:10:05] <BBB> good work [21:10:10] <BBB> I'll review the patch later [21:10:13] <BBB> doing something else now [21:10:30] <BBB> does it play files from http://www-user.tu-chemnitz.de/~womar/projects/iffanim/iffanim_samplepack.z… now? [21:10:33] <BBB> none of them work :( [21:12:21] <bcoudurier> ooooaaaah [21:12:35] <bcoudurier> I can't believe nobody activated audio stream header parsing for mkv [21:12:46] <bcoudurier> no wonder why it's been a long standing issue [21:14:27] <BastyCDGS> bbb, how it can play iffanim? that's a patch fixing an issue with the original iff demuxer [21:14:41] <BastyCDGS> I'll apply the new stuff now to iffanim and see how it works [21:14:56] <BBB> I guess... [21:15:02] <BBB> make them work ;) [21:20:18] <CIA-7> ffmpeg: bcoudurier * r22925 /trunk/libavformat/matroskadec.c: parse stream headers for audio streams in mkv, needed for frame size [21:22:08] <BBB> bcoudurier: should that be vertically aligned? </nag> [21:23:39] <bcoudurier> what should ? [21:24:04] <BBB> the statements around the code in the patch you just applied [21:24:38] <CIA-7> ffmpeg: bcoudurier * r22926 /trunk/libavformat/matroskadec.c: seems aac gets screwed up by the parser so disable it [21:24:43] <bcoudurier> yes indeed, though nobody aligned the H264 one [21:25:13] <BBB> until I understand h264, I'll pretend it's black magic that I should not look at [21:25:37] <Dark_Shikari> bah it isn't that hard =p [21:26:19] <bcoudurier> the specs give headache [21:26:31] <mru> h264 isn't so bad [21:26:35] <mru> the spec is almost readable [21:26:40] <mru> and it mostly makes sense [21:26:45] <mru> compare that to the mpeg4-2 spec [21:26:46] <BBB> it takes 10 years to read [21:26:49] <mru> yuck [21:27:42] <Dark_Shikari> well, the spec loves copy-pasting [21:27:45] <Dark_Shikari> see svc [21:28:05] <Dark_Shikari> bcoudurier: the best parts of the spec are those that seem basically designed to mislead you about subtle things [21:28:10] <Dark_Shikari> Something we discovered recently, for example [21:28:41] <Dark_Shikari> the spec would lead you to believe that it is impossible to have two consecutive duplicate reference frames in a reference list post-reordering [21:28:55] <Dark_Shikari> because the syntax element is difference_between_frame_nums_minus1 or whatever [21:28:58] <Dark_Shikari> and is an unsigned exp-golomb code [21:29:06] <Dark_Shikari> .... But if you make a really really large value [21:29:10] <Dark_Shikari> in particular, (max_frame_num-1) [21:29:13] <Dark_Shikari> it'll wrap around and go back to zero. [21:29:25] <Dark_Shikari> Thus allowing two consecutive frames of the same frame_num in the reference list. [21:29:35] <Dark_Shikari> One of my stream analyzers bitches like crazy because it doesn't realize this is valid. [21:29:38] <kierank> they just talked about it on jvt-experts as if it was a normal thing to do [21:29:39] <BBB> bcoudurier: oh, for AAC fun, check http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs/rdt_8c-source.html line 428 [21:29:42] <kierank> even though it's a bit weird [21:29:50] <BBB> bcoudurier: that works for me [21:29:55] <Dark_Shikari> kierank: yeah [21:29:57] <Dark_Shikari> that too [21:30:49] <bcoudurier> WHAT ? [21:30:53] <bcoudurier> BBB please... [21:31:03] <bcoudurier> this issue should have been fixed _years_ ago [21:31:22] <Dark_Shikari> lol what [21:31:23] <bcoudurier> as a developper I would have expected more motivation ;) [21:31:28] <BBB> bcoudurier: I wrote that code long before I had half a clue... I sill have no clue mostly [21:31:44] <bcoudurier> well 2 options [21:31:45] <BBB> I still don't know what the issue is, for example [21:31:50] <BBB> I know this works :) [21:31:53] <bcoudurier> we cannot compute frame size from extradata [21:31:58] <BBB> I think aacdec doesn't set framesize [21:32:03] <bcoudurier> easy, just add a function that parse extradata and compute frame size [21:32:14] <bcoudurier> otherwise we need to extend the parser [21:32:23] <BBB> the parser/decoder should set it imo [21:32:33] <bcoudurier> it does [21:32:38] <BBB> uh... [21:32:41] <BBB> then why doesn't it get set? [21:32:43] * BBB confused [21:32:44] <bcoudurier> problem is that the parser/decoder is called _after_ [21:32:49] <bcoudurier> the timestamps interpolation [21:32:52] <bcoudurier> no [21:32:58] <bcoudurier> the parser is called _before_ [21:33:04] <bcoudurier> the decoder is called _after_ [21:33:14] <bcoudurier> so if the decoders sets it, it's too late for the first frame [21:33:31] <BBB> so what is the bug? [21:33:36] <BBB> I can't remember what bug it fixed [21:33:38] <peloverde> Isn't that what try_decode_frame is for? [21:33:39] <BBB> but it fixed a bug I was having [21:33:45] <bcoudurier> peloverde, it is for that [21:33:50] <bcoudurier> but it is called after the parsing [21:33:57] <bcoudurier> so if the packet contains multiple frames [21:34:05] <bcoudurier> and the frame size is not computed in the parser [21:34:12] <bcoudurier> the first frames will have wrong timestmaps [21:34:29] <bcoudurier> guys [21:34:35] <bcoudurier> am I the only one who digged into that code ? [21:34:47] <bcoudurier> dug ? [21:34:52] <BBB> I probably digged into it and gave up because it's such a big mess of things I don't get [21:35:01] <BBB> I apologize for the hack though [21:35:52] <bcoudurier> [matroska @ 0x15a2440]av_read_packet stream=1, pts=12, dts=-9223372036854775808, size=846, duration=0, flags=1 [21:35:52] <bcoudurier> [matroska @ 0x15a2440]av_read_frame_internal stream=1, pts=12, dts=12, size=846, duration=0, flags=1 [21:35:52] <bcoudurier> [matroska @ 0x15a2440]av_read_packet stream=1, pts=-9223372036854775808, dts=-9223372036854775808, size=887, duration=0, flags=0 [21:35:52] <bcoudurier> [matroska @ 0x15a2440]av_read_frame_intern[matroska @ 0x15a2440]av_read_packet stream=1, pts=12, dts=-9223372036854775808, size=846, duration=0, flags=1 [21:35:54] <bcoudurier> [matroska @ 0x15a2440]av_read_frame_internal stream=1, pts=12, dts=12, size=846, duration=0, flags=1 [21:35:54] <peloverde> bcoudurier, the frame size in *time* can be trivially computed from the headers [21:35:56] <bcoudurier> [matroska @ 0x15a2440]av_read_packet stream=1, pts=-9223372036854775808, dts=-9223372036854775808, size=887, duration=0, flags=0 [21:36:01] <bcoudurier> [matroska @ 0x15a2440]av_read_frame_internal stream=1, pts=12, dts=12, size=887, duration=21, flags=1 [21:36:03] <bcoudurier> al stream=1, pts=12, dts=12, size=887, duration=21, flags=1 [21:36:05] <bcoudurier> this is pretty obvious [21:36:08] <peloverde> the frame size in *samples* cannot [21:36:33] <bcoudurier> that's a problem [21:36:40] <bcoudurier> _but_ if the duration can be set [21:36:47] <bcoudurier> it should be fine [21:36:57] <bcoudurier> I mean mkv packet duration [21:37:23] <bcoudurier> was it _too_ hard to put a frame size field in mkv ? [21:37:30] <bcoudurier> I mean mov has it since _years_ [21:38:41] <BBB> mkv is like ogg [21:38:43] <BBB> they first design [21:38:46] <BBB> then they release [21:38:48] <BBB> then they wait for bugs [21:38:51] <BBB> then it's too late [21:38:57] <BBB> "oops" [21:38:57] <mru> lol [21:39:06] <peloverde> The frame size in time is the (1024-64*frame_length_flag)/nominal_sample_rate [21:39:15] <mru> BBB: one difference [21:39:24] <mru> the mkv guys at least tried to get it right [21:39:32] <BBB> I guess [21:39:44] <saintdev> mru: isn't the difference that ogg never had the "first design" step [21:39:57] <mru> that too [21:40:19] <bcoudurier> well they messed up the nomenclature [21:40:25] <bcoudurier> and I will never forgive them for this [21:40:40] <bcoudurier> now everybody is confusing time codes and timestamps [21:41:10] <peloverde> also you can use OutputSamplingFrequency to detect SBR and simplify the whole mess [21:41:18] <BBB> bcoudurier: it's well possible if you fix your bug in mov, I can remove that crazy code from rdt as well [21:41:33] <bcoudurier> mov has no bug [21:41:35] <bcoudurier> ;) [21:41:38] <BBB> so please allow me to sit back, relax and do nothing while you fix the bug. . . . . <waits to be kicked> [21:41:59] <bcoudurier> which bug are talking about ? [21:42:09] <BBB> the part where you need if (.. AAC ..) in mov.c [21:42:25] <BBB> might not be a bug IN mov.c [21:42:27] <bcoudurier> peloverde, how is the fastest way to compute the frame size ? [21:42:29] <BBB> but it's a bug involving mov.c [21:42:34] <bcoudurier> can it be done in the parser ? [21:42:50] <peloverde> which parser [21:42:53] <bcoudurier> aac [21:42:57] <peloverde> MO! [21:43:00] <peloverde> *No! [21:43:03] <peloverde> No no no no no no no [21:43:07] <peloverde> don't use the AAC parser [21:43:08] <bcoudurier> if AAC in mov.c is when reading esds [21:43:20] <bcoudurier> that is no bug [21:43:25] <BBB> peloverde: is it broken? can you fix it? [21:43:32] <bcoudurier> well then in the matroska demuxer [21:43:41] <peloverde> BBB, it's not broken [21:43:49] <BBB> but... [21:43:50] <peloverde> it has a specific purpose [21:44:00] <BBB> which is...? [21:44:06] <peloverde> it's not some panacea to be cargo culted around [21:44:11] <bcoudurier> btw, IMHO the parser should not garble the bitstream [21:44:12] <peloverde> to parse raw ADTS streams [21:44:31] <peloverde> the parser has to bitstream sync [21:44:37] <BastyCDGS> sorry was away [21:44:49] <peloverde> if you are sending wrong data to the parser you should expect funny results [21:45:16] <peloverde> if you sent h.264 to the ac3 parser you'd get funny results [21:45:21] <bcoudurier> peloverde, if should support PARSE_HEADERS though [21:45:25] <bcoudurier> and not search for sync [21:45:41] <peloverde> the aac_parser should really be called adts_parser [21:45:53] <bcoudurier> probably [21:46:04] <peloverde> if you send non adts data to it, it tries to make it adts [21:46:22] <bcoudurier> ? [21:46:40] <bcoudurier> it just splits the bitstream on adts headers [21:46:41] <Yuvi> bcoudurier: pong [21:46:48] <peloverde> yes [21:47:06] <bcoudurier> Yuvi, I activated header parsing for audio streams in mkv [21:47:09] <peloverde> for aac in mkv there are no headers to be parsed [21:47:14] <bcoudurier> the last goal is to compute aac frame size [21:47:40] <bcoudurier> indeed, no headers, but mkv sets PARSE_HEADERS [21:47:43] <bcoudurier> no PARSE_FULL [21:47:46] <peloverde> if some idiot shoved full adts frames into mkv for some retarded reason, the decoder can deal with that just fine on its own [21:47:55] <bcoudurier> PARSE_HEADERS must only call "fetch params" [21:48:00] <Yuvi> full adts in mkv is a spec violation [21:48:02] <bcoudurier> and not cut the stream [21:48:13] <peloverde> Yuvi, FFmpeg does it by default [21:48:17] <bcoudurier> look at other parsers [21:48:22] <peloverde> then that's a bug in the aac_parser [21:48:30] <peloverde> which is whomever is the parser mainters problem [21:48:55] <bcoudurier> nice [21:49:13] <bcoudurier> are you angry at something ? [21:49:51] <Yuvi> from what source / isn't GLOBAL_HEADERS supposed to specify raw aac? [21:49:51] <BBB> I think we bug him too much about aac problems that he didn't cause ;) [21:49:56] <peloverde> I went though this same exact situation with the gstreamer people for *months* [21:50:36] <BBB> Dark_Shikari: re-ping [21:50:39] <Dark_Shikari> pong [21:50:44] <BBB> Dark_Shikari: qcelp ;) [21:50:50] <Dark_Shikari> I'm waiting for a link. [21:50:52] <BBB> (ok, not exactly 20 min, but close enough) [21:51:11] <BBB> Dark_Shikari: http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/107976 [21:51:26] <BBB> specifically http://people.gnome.org/~rbultje/ff/ r1-3.wav [21:51:40] <Yuvi> btw, is there any reason (besides parsers that appear to modify the bitstream) to not make PARSE_HEADERS the default? [21:51:41] <BBB> if you wish, also look at resampled-dec-qt.wav, but you don't have to [21:51:48] <Yuvi> for everything [21:51:55] <Dark_Shikari> BBB: which ones [21:51:59] <Dark_Shikari> ok, r1-3 [21:52:02] <BBB> yeah [21:52:47] <bcoudurier> peloverde, I understand the frustration [21:53:27] <BBB> peloverde: renaming aac_parser would help a lot, I was confused by it also [21:53:51] <peloverde> I find file renames too bikesheddy to participate in [21:54:08] <peloverde> plus again I am not the maintainer [21:54:17] <BBB> hmk [21:54:25] <BBB> non-maintainers are allowed to submit patches [21:54:33] <Dark_Shikari> BBB: 2 > 3 > 1 [21:54:49] <peloverde> BBB, then feel free to submit a patch :) [21:55:06] <bcoudurier> ... [21:55:15] <astrange> it's impolite to rank samples without abxing first [21:55:19] <BBB> Dark_Shikari: can you do that on-list? [21:55:27] <Yuvi> peloverde: ffmpeg -acodec aac blah.mkv seems to do raw aac, is it something else that does adts? [21:55:45] <peloverde> Yuvi, do a stream copy from an adts file [21:55:58] <Dark_Shikari> BBB: why [21:56:08] <BBB> Dark_Shikari: so I have documentation of this test [21:56:08] <peloverde> Yuvi, ffmpeg -i file.aac -acodec copy blah.mkv [21:56:20] <Dark_Shikari> mru: very nice bikeshed argument going there btw [21:56:21] <Dark_Shikari> congrats [21:56:23] <BBB> Dark_Shikari: alternatively, can I c/p that sentence in an email on-list? [21:56:38] <Dark_Shikari> sure. [21:56:50] <Dark_Shikari> oh hmm, just realized I tested with the noise sharpening postprocessor on [21:56:53] <Dark_Shikari> I wonder if that changes the results. [21:56:58] <BastyCDGS> IFF-ANIM now reads all chunks [21:56:59] <peloverde> is there a parser to look at that differentiates between parse_headers and parse_full? [21:57:16] <Dark_Shikari> hmm, doesn't seem so. no HF content in the source anyways [21:57:25] <peloverde> sometimes I really think we should treat adts as a muxed format [21:57:27] <BastyCDGS> just have now to figure out how to ensure that each frame gets one unique image [21:57:35] <peloverde> it would solve a ton of problems [21:57:45] <mru> peloverde: but mpeg-[pt]s carries adts [21:57:48] <Yuvi> peloverde: I agree, is there any reason (e.g. same problems as latm) not to? [21:57:54] <peloverde> mru, chaindemux [21:57:59] <mru> we don't have that [21:58:11] <Dark_Shikari> we do [21:58:12] <Dark_Shikari> dv in mov [21:58:12] <bcoudurier> have fun [21:58:14] <Dark_Shikari> etc [21:58:19] <peloverde> dv in mov [21:58:23] <bcoudurier> dv is fixed frame size [21:58:23] <BBB> asf in rtsp [21:58:24] <mru> we don't have proper chaindemux [21:58:27] <mru> only piles of hacks [21:58:28] <BBB> mru: true [21:58:33] <Dark_Shikari> we can do vorbis in ogg in avi! [21:58:35] <mru> because some people refuse to realise the need for it [21:58:43] <mru> there are specs for mpegts in mp4 [21:58:45] <Dark_Shikari> mru: we totally need to support ogg in avi! [21:58:51] <peloverde> pseudochaindemux seems less hackish than the giant pile of adts hacks we have [21:58:53] <kierank> [22:57] <@Yuvi> peloverde: I agree, is there any reason (e.g. same problems as latm) not to? --> and 337m [21:58:59] <kierank> I would like to see this too [21:59:01] <peloverde> and the completely stalled LATM situation [21:59:03] <bcoudurier> what adts hacks ? [21:59:09] <kierank> it would remove current dirty hacks I have in my tree as well [21:59:20] <mru> latm in ts in mp4... [21:59:31] <mru> in http in ip in mpegts [21:59:34] <bcoudurier> oh you guys are good a complaingin [21:59:46] <bcoudurier> international ranking [21:59:53] <peloverde> sometimes a bsf is needed with ADTS sometimes it isn't the users have no idea [22:00:16] <bcoudurier> how can 337m need a demuxer on his own ? [22:00:27] <bcoudurier> peloverde, a _lot_ of SDKs supports 3 forms [22:00:32] <bcoudurier> adts, raw, latm [22:01:10] <kierank> bcoudurier: as we discussed a while ago the idea of having multiple programs that the container views as only 1 [22:01:53] <BBB> BastyCDGS: good work so far, keep it uop [22:01:54] <peloverde> bcoudurier, then you explain to users why then need a magical incantation to properly remux adts files [22:02:13] <BBB> BastyCDGS: I'm hoping that you sort of get a feel of the way demuxers/decoders are done in ffmpeg this way [22:02:14] <bcoudurier> you don't need to explain them [22:02:16] <kierank> dolby e in 337m in 302m in ts is going to be very ugly [22:02:18] <bcoudurier> you reformat in the muxer [22:02:25] <bcoudurier> like the ts/mp4 muxer does [22:02:41] <bcoudurier> or you add a mechanism to automatically insert a bitstream filter [22:02:48] <bcoudurier> or you add the code to do that in ffmpeg.c [22:02:48] <BastyCDGS> I got already a bit thanks to the bug fixing stuff [22:02:58] <bcoudurier> seriously there are _tons_ of way to do it [22:03:01] <BastyCDGS> with this knowledge it makes it lots easier [22:03:02] <bcoudurier> but you guys complain [22:03:28] <bcoudurier> if you are lazy but have something _working_ [22:03:33] <bcoudurier> I'm _ok_ with it [22:03:37] <bcoudurier> and will say so on the ml [22:03:49] <bcoudurier> we must stop find excuses [22:03:54] <peloverde> bcoudurier, no it doesn't [22:03:56] <bcoudurier> finding [22:04:18] <bcoudurier> doesn't what ? [22:04:29] <peloverde> ffmpeg -i al18_64.adts -acodec copy copy.mp4 [22:04:37] <bcoudurier> not mp4 [22:04:46] <bcoudurier> err not aac [22:04:48] <bcoudurier> but h264 [22:04:58] <bcoudurier> ts does mp4 -> adts automatically though [22:05:08] <bcoudurier> depending on the usage [22:05:15] <peloverde> and I quote: "6D 64 61 74 FF F0" [22:05:24] <BastyCDGS> Input #0, IFF, from '../../ffmpeg-svn.orig/patches/anim-j/BoingThrows/BoingThrows': [22:05:24] <BastyCDGS> Duration: N/A, bitrate: N/A [22:05:24] <BastyCDGS> Stream #0.0: Video: iff_anim, pal8, 320x200, PAR 10:11 DAR 16:11, 90k tbr, 90k tbn, 90k tbc [22:05:30] <BastyCDGS> but no window yet :( [22:06:08] <BastyCDGS> [iff_anim @ 0x8b30730]palette data underflow [22:06:08] <BastyCDGS> ../../ffmpeg-svn.orig/patches/anim-j/BoingThrows/BoingThrows: could not open codecs [22:06:37] <bcoudurier> in any case, I don't see what you are trying to prove [22:07:38] <BBB> BastyCDGS: that's because no video is decoded yet [22:07:45] <BBB> BastyCDGS: you need to make a video decoder next [22:07:48] <peloverde> If it's so trivial then why don't the demuxers you maintain support it? [22:07:49] <BBB> only then do you see video being displayed [22:08:10] <BastyCDGS> no the first image is standard IFF-ILBM [22:08:17] <BastyCDGS> this should be shown already [22:08:23] <BastyCDGS> the special stuff starts with the delta frames [22:08:49] <bcoudurier> what are you talking about [22:09:01] <bcoudurier> have we add so many request for adts to mp4 ? [22:09:09] <bcoudurier> _no_ [22:09:16] <bcoudurier> then I don't see the point [22:09:22] <BastyCDGS> a wait this is a stub right now, just try it with calling the original for a moment [22:09:29] <bcoudurier> however mp4 -> ts [22:09:32] <bcoudurier> _yes_ [22:09:35] <bcoudurier> so the ts muxer does it [22:09:44] <Yuvi> doesn't mp4 only allow raw aac? [22:09:48] <bcoudurier> if you want to do it feel free to do so [22:09:54] <bcoudurier> wtf [22:10:00] <bcoudurier> if you don't, don't complain [22:10:01] <BBB> BastyCDGS: right, your decoder is a stub [22:10:01] <peloverde> plenty of people remux adts aac to mp4 [22:10:07] <BBB> BastyCDGS: so change that first [22:10:09] <bcoudurier> not using ffmpeg [22:10:16] <bcoudurier> and I don't see any bugreport [22:10:16] <peloverde> and ffmpeg happily creates a broken stream [22:10:28] <bcoudurier> so what ? it's a bug [22:10:30] <peloverde> but ffmpeg and faad will happily play the broken stream [22:10:34] <peloverde> so most don't notice [22:10:41] <peloverde> but it's still wildly out of spec [22:10:52] <bcoudurier> so in other words it's not a big deal [22:11:00] <peloverde> there are tons of mp4s in the wild that have whole adts frames in them [22:11:16] <Yuvi> quicktime won't play such files for one [22:11:17] <peloverde> it's a big deal because it's out of spec [22:11:19] <bcoudurier> well I guess that was meant to happen [22:11:27] <peloverde> and other implementations don't support it [22:11:44] <bcoudurier> there's only one rule [22:11:47] <bcoudurier> people complaining [22:11:53] <bcoudurier> do users complain ? [22:12:06] <bcoudurier> I don't see that many [22:12:22] <bcoudurier> would people complain if they had to add -vbsf h264_annexbtomp4 every time ? [22:12:25] <bcoudurier> _yes- [22:12:29] <peloverde> FAAC encodes 5.1 aac as SCE.0 CPE.0 CPE.0 LFE.0, completely broken but faad plays it so no problem, right? wrong it buts heads with features faad doens't support makign supporting that brokeness in ffmpeg a nightmare [22:12:31] <bcoudurier> so mp4 muxer does it internally [22:12:48] <bcoudurier> it's easier for everybody [22:13:09] <peloverde> people don't complain because ti seems to work, then the file is subtly broken when they take it elsewhere [22:13:12] <bcoudurier> well, avi is borken [22:13:13] <BBB> guys, don't kill each other please [22:13:18] <bcoudurier> if you don't play broken avis [22:13:22] <bcoudurier> you play 20% of avis [22:13:27] <bcoudurier> and people will use something else [22:13:32] <bcoudurier> it's up to you [22:13:45] <peloverde> when did avi come up? [22:13:52] <Yuvi> this isn't about playing broken files, it's about generating them and adding to the brokeness problem [22:14:13] <peloverde> Yuvi: correct [22:14:29] <_Jonas_> hi all, i have found a small buffer overflow bug, http://pastie.org/926949 [22:14:34] <peloverde> standards should be followed strictly for output [22:14:36] <BastyCDGS> I have found the issue with the colormap [22:14:45] <BastyCDGS> it's because HAM & EHB aren't supported yet [22:15:15] <BastyCDGS> i.e. 4096 color mode and 262144 color mode [22:15:47] <peloverde> and the problem is that this doesn't just happen with mp4, it happens with every single muxer that uses a aac with a global header [22:17:17] <BastyCDGS> what about dropping that crazy iff.h stuff I added and use IffDemuxContext instead [22:17:24] <BastyCDGS> like I did with position storing [22:17:44] <_Jonas_> or is this the wrong channel for this ? [22:18:52] <Yuvi> for aac, is ts the only container we support muxing for that requires adts? [22:18:59] <peloverde> _Jonas_, file something in the bug tracker so it doesn't get lost [22:20:02] <peloverde> The ADTS muxer creates ADTS [22:20:12] <peloverde> but interestingly it requires the data in mp4 format [22:22:11] <bcoudurier> creating broken files is a bug [22:22:23] <bcoudurier> and I'm not talking about this problem [22:22:31] <bcoudurier> no [22:22:34] <bcoudurier> the adts muxer supports both [22:22:38] <BastyCDGS> not if you're microsoft then it's a feature haha [22:22:44] <bcoudurier> it will parse extradata if it is present [22:22:51] <bcoudurier> like the ts muxer [22:23:30] <BBB> BastyCDGS: that's indeed the idea, to continue using iffdemuxcontext for this stuff [22:23:39] <BBB> (demuxing-related) [22:27:10] <Yuvi> hm, does anything support both raw aac and adts, or could we just assume GLOBAL_HEADERS == raw, and adts otherwise? [22:27:20] <Yuvi> for muxing [22:29:00] <Yuvi> well the second half worn't work [22:29:06] <bcoudurier> we should be able to assume that [22:29:43] * peloverde looks at all the duplication between the adts muxer and the aac decoder [22:32:47] <peloverde> also for what it's worth the ADTS muxer doesn't seem to remux adts streams at all, merely pass them though [22:34:03] <bcoudurier> what's the problem ? [22:34:14] <bcoudurier> factorizing code is welcome [22:34:25] <peloverde> I didn't say it's a problem, I said for what it's worth [22:34:50] <peloverde> people may try to remux shoddily muxed adts files and wonder why they are still shoddily muxed [22:35:03] <peloverde> i.e. bad adts_buffer_fullness [22:35:17] <bcoudurier> ... [22:35:23] <peloverde> or try to remove the crc [22:35:40] <bcoudurier> you should relax a bit [22:35:40] <peloverde> or want to normalize everything as mpeg-4 [22:35:51] <BastyCDGS> did a commit to ml for iff-anim [22:35:56] <bcoudurier> feel free to fix things [22:36:08] <peloverde> I've spent a lot of time thinking about how to make the adts muxer more flexible [22:36:34] <bcoudurier> you can do whatever you want [22:36:52] <bcoudurier> with the adts muxer [22:36:52] <bcoudurier> seriously [22:37:13] <peloverde> do we have some sort of normalize/super-remux flag [22:37:15] <bcoudurier> well for what is worth it seems the bitstream filter is not flexible at all [22:37:25] <bcoudurier> feel free to add it [22:39:17] <BastyCDGS> is there a way to set panning in ffmpeg in audio sample? [22:39:30] <BastyCDGS> i ask because iff-anim has 3 modes, left, right, center [22:39:47] <BastyCDGS> want do set pan to 0x80 (if ranges from 0-255) for center mode [22:40:24] <bcoudurier> [NULL @ 0x3084d00]Multiple RDBs per frame with CRC is not implemented. Update your FFmpeg version to the newest one from SVN. If the problem still occurs, it means that your file has a feature which has not been implemented. [22:40:24] <bcoudurier> aac_adtstoasc failed for stream 0, codec copy: Operation not permitted [22:40:57] <peloverde> Are you filtering something with multiple RDBs? [22:41:12] <BBB> BastyCDGS: ? what's that? [22:41:23] <peloverde> All I know is that people constantly yammer on about how AAC is completely unnecessary because we have MP3 or Vorbis or AC-3 already, then constantly complain to me about how broken FFmpeg's AAC support is when the only brokenness that is actually my fault is the encoder [22:41:26] <BastyCDGS> panning? stereo position... [22:41:40] <bcoudurier> I really don't blame you [22:41:53] <BBB> BastyCDGS: "ffmpeg" has no panning, the decoder should take care of that, no? [22:41:59] <BastyCDGS> 0 is left, 255 is right, 128 is center, 64 would be left channel 75% of volume, right channel 25% [22:42:13] <bcoudurier> the aac file is from mp4 [22:42:15] <BBB> is that part of the audio packet? [22:42:17] <bcoudurier> -acodec copy test.aac [22:42:20] <BastyCDGS> yes [22:42:24] <BastyCDGS> audio pkt [22:42:25] <bcoudurier> either the parser did fuck up [22:42:28] <bcoudurier> or something is wrong [22:42:44] <BastyCDGS> so I will solve this by output the same sample on left and right channel [22:43:02] <BBB> BastyCDGS: uh ok, but again, focus on video, not audio [22:43:09] <BBB> for now, video is your task, not audio ;) [22:43:24] <bcoudurier> AAC is clearly useful [22:43:58] <bcoudurier> I don't know who tells you about mp3 and ac-3 [22:44:04] <bcoudurier> everybody use aac [22:44:19] <peloverde> ffmpeg -i in.mp4 -abs aac_adtstoasc out.aac? [22:44:35] <peloverde> ATSC uses AC-3 [22:44:45] <bcoudurier> nope [22:44:57] <bcoudurier> -i in.mp4 -acodec copy out.aac [22:45:11] <peloverde> how is that giving you bsf errors? [22:45:11] <bcoudurier> then out.aac -absf aac_adtstoasc test.mp4 [22:45:15] <peloverde> ahhh [22:45:18] <BastyCDGS> bbb, this is hard considering you're all talking about audio stuff all the time *gg* [22:45:32] <BBB> BastyCDGS: well, ffmpeg is 50% video and 50% audio [22:45:40] <bcoudurier> I was making the muxer to abort if aac is missing extradata [22:45:46] <bcoudurier> so I tested [22:45:47] <BBB> and several of us on irc know more about audio than video, I guess [22:46:04] <bcoudurier> well radio uses he-aac [22:46:11] <bcoudurier> web is using aac [22:46:32] <bcoudurier> tv's support aac now [22:47:06] <peloverde> half the web seems to think that MPEG codecs are a giant conspiracy [22:47:29] <bcoudurier> don't listen to freetards ;) [22:47:42] <bcoudurier> they make a lot of noise indeed [22:48:52] <BBB> +1 to that [22:49:10] <BBB> peloverde: the corporate world, which is what will pay for your job now and forever after, amen, is all mpeg codec [22:49:34] <BBB> peloverde: many still use mp3, but there's a lot of aac+ nowadays [22:49:52] <BBB> and don't forget the biggest website in the world, youtube, which uses aac [22:50:02] <BBB> facebook, hulu, etc. [22:50:03] * Kovensky wonders if anyone but eroge companies use mp2 [22:50:06] <Kovensky> +s [22:50:27] <bcoudurier> mp2 is still used much in broadcast [22:50:45] <bcoudurier> but they work at 384kb anyway [22:51:27] <bcoudurier> for 5.1 they go pcm since the bitrates used for hd are so high anyway [22:51:41] <mru> there's a lot of ac3 too [22:51:45] <BastyCDGS> BBB: can i access IffDemuxContext from a decoder or must I use IffContext there? [22:51:47] <bcoudurier> not in broadcast [22:51:50] <bcoudurier> for iptv [22:51:50] <mru> sure is [22:52:00] <mru> directv-hd is all ac3 [22:52:01] <bcoudurier> you are talking about iptv [22:52:05] <mru> sat [22:52:08] <bcoudurier> or sat same [22:52:16] <bcoudurier> the copy on the server is not ac3 [22:52:21] <mru> and atsc is ac3 [22:52:23] <bcoudurier> it's dolby-e [22:52:25] <mru> a/52 [22:52:30] <bcoudurier> or pcm [22:52:49] <bcoudurier> yes that's for sat/iptv [22:52:56] <mru> and atsc terrestrial [22:53:00] <bcoudurier> ie the last end to the consumer [22:53:01] <mru> it's mp2 and ac3 [22:53:23] <BastyCDGS> one question, is there something like a decryptor layer for stuff like blu-ray copy protection and decss? [22:53:42] <bcoudurier> they don't receive that as a master [22:53:42] <mru> it's much harder than css to break [22:53:44] <mru> but it can be done [22:53:51] <BBB> BastyCDGS: iffcontext [22:54:15] <mru> or did you mean a generic decryption layer in ffmpeg [22:54:16] <BBB> BastyCDGS: anything that needs to go from demuxer to decoder (setitngs or so) should go in the AVPacket or in the AVCodecContext, I'll help you with that tomorrow [22:54:18] <BBB> gotta go now [22:54:39] <peloverde> "ffmpeg -i al00_44.mp4 -acodec copy copy.adts; ffmpeg -i copy.adts -acodec copy -absf aac_adtstoasc out.mp4" seems to work for me [22:54:55] <BBB> BastyCDGS: there's some decryption code in ffmpeg, but it needs a lot of work... so nothing useful for dvd/bluray [22:55:10] <BastyCDGS> i meant more a framework [22:55:25] <BastyCDGS> which links in between demuxer and decoder [22:56:01] <bcoudurier> peloverde, uploading Pirates3.mov in incoming [22:56:08] <peloverde> ok [22:56:30] <bcoudurier> aac-lc created by apple [22:58:08] <BBB> BastyCDGS: there's no such thing yet right now [22:58:34] <BastyCDGS> what about avfilter? isn't that a similar thing? [23:01:41] <BBB> avfilter is for filtering decoded video/audio [23:01:54] <BBB> think noise reduction for audio or rotation for video [23:02:05] <BBB> deinterlacing, etc. [23:05:38] <BastyCDGS> what about a libavdecrypt? [23:05:44] <BastyCDGS> just an idea for a name [23:06:50] <BastyCDGS> or just libavcrypt (for encrypting possibilities) [23:07:02] <BastyCDGS> could also also GPG signed movies with ffmpeg able to verify signature ;) [23:07:54] <BastyCDGS> no fake bin laden movies anymore *g* [23:08:45] <peloverde> GPG signed movies sound kind of busy [23:08:55] <peloverde> err cool [23:15:00] <BastyCDGS> normally it would take some time to verify a 1:30h movie (due to it's file length) [23:15:16] <BastyCDGS> with such a thing like libavcrypt it could verify it during playback [23:15:29] <BastyCDGS> and when the movie is finished you get the result of verification [23:15:48] <mru> and get told you just wasted two hours watching a fake film [23:16:46] <BastyCDGS> at least you know it then ;) [23:17:26] * kierank senses some really crazy idea [23:17:31] <BastyCDGS> but that's just an idea which spontaneously came into my mind, maybe some of you are interested int this... [23:18:06] <kierank> to be honest it made no sense whatsoever [23:19:56] <BastyCDGS> sure, for normal kind of movies it's no sense, but imagine being a NGO where there might be guys interested into making the NGO unseriously and releasing fakes in the name of them [23:20:16] <BastyCDGS> the usecase is proably more or less the same like GPG in mails [23:20:33] <drv> surely you could just verify the whole file with gpg? :) [23:21:03] <janneg> calculating the sha256 of a 700M file takes 20 seconds (empty caches, 5400rpm notebook drive) [23:21:30] <BastyCDGS> that's always an option...;) [23:22:00] <janneg> 7s user time [23:23:08] <BastyCDGS> where you are mentioning sha256 you can even do this blockwise, thus even while watching it, just sha the frame ;) [23:23:27] <mru> to what end? [23:24:29] <BastyCDGS> but GPG was just another example, libavcrypt is more useful for css and hdmi stuff, undoubtfully [23:24:50] <mru> hdcp is done at the link level [23:24:56] <mru> by hardware [23:25:39] <BastyCDGS> if it becomes the signal from software to do it... [23:25:55] <BastyCDGS> but it wouldn't get active, if ffmpeg would decrypt it by own ;) [23:25:57] <mru> that's outside the scope of ffmpeg [23:26:28] <mru> ffmpeg only goes as far as decoding and a bit of post-filtering [23:26:49] <mru> hdcp is handled by the display driver [23:29:11] <BastyCDGS> it isn't really a high (not even medium) priority for me either...thought is as a long term project if at all [23:29:59] <janneg> are there even hdmi capture devices? [23:31:57] <kierank> yes [23:32:20] <kierank> some of them can strip hdmi as well [23:32:49] <janneg> s/hdmi/hdcp/? [23:33:16] <mru> janneg: ever heard of a tv? [23:33:57] <janneg> yes, even of tvs running ffmpeg [23:34:08] <kierank> janneg,yes [23:34:28] <mru> I doubt the hdmi signal goes to ffmpeg though [23:34:41] <mru> they use ffmpeg for decoding stuff from other sources [23:34:44] <janneg> but I doubt the processor of the tv has access to the hdmi signal though [23:35:40] <janneg> I'm still looking for use cases of hdcp decoding in ffmpeg [23:35:42] <kierank> mru: I thought it was just using ffmpeg for demuxing in the tvs? [23:35:59] <mru> I've no idea what they use it for [23:36:12] <mru> but I'm sure it's nothing to do with raw video from hdmi [23:41:08] <janneg> wtf: samung has distributes a ffmpeg.zip of the full svn checkout, i.e. including .svn dirs [23:41:19] <Dark_Shikari> Seems easy enough [23:41:26] <Dark_Shikari> was it samsung that had that massive wtf of code modifications? [23:41:39] <mru> they had some weird changes [23:41:48] <mru> but they're playing by the rules [23:41:53] <mru> in a nice way even [23:41:56] <BastyCDGS> did they released the changes within GPG [23:42:00] <BastyCDGS> ah ok [23:42:29] <mru> the full svn checkout means it's easy to see exactly what they did [23:42:52] <mru> we've seen others who release some bizarre hybrid of multiple revisions mixed up with their own changes [23:43:22] <janneg> 33 files changed, 2569 insertions(+), 518 deletions(-) [23:44:11] <janneg> they even ship their config.h|mak [23:44:55] <kierank> hehe they added latm [23:46:14] <kierank> and drm metadata crap [23:46:23] <janneg> and AES decryption to the mpegts demuxer [23:47:06] <kierank> weird, aes seems to be for the freesat spec [23:47:39] <kierank> weird that totally fta satellite service would need that [23:47:42] <kierank> a* [23:48:17] <kierank> ah, it's for bbc iplayer [23:48:31] <BastyCDGS> do you plan to add any of the samsung stuff into ffmpeg mainline tree? [23:48:59] <peloverde> I believe we've picked over it a few times already [23:52:29] <bcoudurier> latm ? :) [23:52:32] <bcoudurier> they made it work hehe [23:52:53] <peloverde> they don't have to remux anything [23:53:07] <janneg> some version of paul kendall's patches [23:54:10] <bcoudurier> remux is another step IMHO [23:54:31] <bcoudurier> if decoding works, they can transcode at least [23:54:53] <peloverde> because transcode is usually a good option with lossy audio [23:56:07] <janneg> and they aren't even using it. it requires libfaad and they don't enable it [23:56:19] <bcoudurier> it's _better_ than nothing in all cases ! [23:56:49] <bcoudurier> seriously, this is depressing [23:56:54] <peloverde> or we could just chain demux [23:57:06] <bcoudurier> then work on it [23:57:16] <peloverde> we already support chaindemux [23:57:26] <peloverde> see dv in mov and ogg vorbis in avi [23:57:37] <bcoudurier> ?? [23:57:57] <Dark_Shikari> we don't support ogg in avi [23:57:59] <bcoudurier> add chaindemux in the mpegts demuxer [23:58:03] <bcoudurier> if you wanbt [23:58:09] <bcoudurier> I don't fucking care [23:58:15] <bcoudurier> do what you want but make it work ! [23:58:22] <bcoudurier> and stop complaining [23:58:39] <peloverde> you're the one complaining IIRC [23:58:47] <bcoudurier> are you kidding me ? [23:59:01] <peloverde> you were the one bitching about the parser [23:59:08] <bcoudurier> I only hear you complaining here [23:59:33] <bcoudurier> I'm not bitching about it [23:59:37] <bcoudurier> I'm asking you for solutions [23:59:40] <bcoudurier> on getting the aac frame size [23:59:45] <bcoudurier> your answer ?

1 0