[00:05:01] <mru> here's another good error message: UNREACHABLE executed! [00:05:11] <Sean_McG> o_O; [00:05:24] <mru> followed by a stack dump [00:06:50] <peloverde> when they say better errors I think they mean from the parser, that sounds like an ICE [00:06:57] <mru> yeah [00:07:28] <mru> I was just a bit surprised to see it [00:07:41] <mru> all I did was ask it to build for darwin [00:08:05] <mru> clearly I wasn't supposed to do that [00:08:11] <Sean_McG> heheheh [00:10:10] <roxfan> at least you didn't get "impossible happened" [00:10:20] <mru> actually, that's what it says [00:10:31] <roxfan> "The most irritating message while using ICL Algol 68 error was [00:10:31] <roxfan> Impossible Happened [00:10:31] <roxfan> Adding a blank card could fix the problem." [00:10:55] <mru> you sound old [00:11:04] <roxfan> i am quoting :) [00:11:15] <mru> ah, so you are [00:13:26] <Yuvi> mru: Sounds like an internal error in mc (the integrated asaembler$ [00:13:40] <mru> Yuvi: which one? [00:14:04] <Yuvi> The error interfacing with taeget maxhine [00:15:22] <peloverde> saintd3v: do we want to initialize the bit reservoir to the full 6144? [00:16:28] <Yuvi> And yeah, the ICE error messages aren't helpful to users; theyre stripped out of release builds even I think [00:17:18] <mru> the "interface with target machine" error is reported from EmitAssemblyHelper::AddEmitPasses() [00:17:37] <mru> which lives in clnag/lib/CodeGen/BackendUtil.cpp [00:20:53] <peloverde> also as far as num_bark does shouldn't we use calc_bark(sample_rate/2)? [00:24:29] <mru> Yuvi: it never gets as far as actually doing anything [00:24:50] <mru> if my interpretation of -debug-pass is correct [00:25:13] <mru> with working targets, -debug-pass=Executions prints lots of stuff [00:25:20] <mru> when this error occurs, it prints nothing [00:30:24] <peloverde> saintd3v: as far as the energy spreading stuff goes, is there a separate patch somewhere. Did I miss it? [00:34:33] <peloverde> also can you break out the parts that are just reorganizing code? Alternatively I can do it [00:34:43] <peloverde> I just don't want to screw up your patch set [00:59:54] <Sean_McG> why the hell does GNU Make swallow up $O from $ORIGIN in a Makefile? [01:00:26] <mru> $(name) [01:04:09] <lu_zero> fun... [01:04:35] * lu_zero is trying to convince ffmpeg to streamcopy an additional video track... [01:04:50] <Dark_Shikari> -vcodec copy -newvideo? [01:04:58] <Sean_McG> now it's trying to substitute for that variable... [01:05:21] <peloverde> saintd3v: maybe we should continue this discussion on a medium less ephemeral than irc [01:05:24] <lu_zero> Dark_Shikari: yup [01:05:26] <lu_zero> but [01:05:30] <lu_zero> after the filename [01:05:37] <lu_zero> Aaand [01:05:44] <Dark_Shikari> yup [01:05:56] <lu_zero> you might not get anything in the stream =P [01:07:32] <lu_zero> now I'm wondering what's wrong with it [01:07:36] <mru> Sean_McG: oh, you want $$ORIGIN then, if you want the $ literal [01:07:58] <Sean_McG> I do... and I just tried that but it's still substituting [01:08:00] <lu_zero> since using output_example to create nut files work well [01:08:26] <lu_zero> creating ts ones does not at all [01:19:28] <Compn> ffmpeg needs playlist/concat support [01:21:38] <lu_zero> Compn: first it'd need to have more sense =P [01:23:09] <saintdev> peloverde: hehe [01:23:39] <saintdev> i scared him off 0_0 [01:37:05] <saintdev> <peloverde> saintd3v: do we want to initialize the bit reservoir to the full 6144? <-- i didn't think so, but that's what i thought 3gpp did. however it does not. i was looking at the wrong variable. [01:37:39] <peloverde> ok [01:37:50] <saintdev> peloverde: also 6144 is per channel? [01:38:34] <peloverde> yes, per channel [01:41:30] <saintdev> num_bark - should be bandwidth (as the comment says), but we don't have a cutoff currently. so sample_rate/2 should be correct. [01:42:54] <saintdev> yes energy spreading is a separate patch, once i finished it, i realized it would be rather useless without the rest of this, so i was just going to combine the patches [01:43:58] <saintdev> most of the cosmetics are split out already [01:46:10] <peloverde> the last hunk of aacpsy.c looks purely cosmetic [01:46:47] <peloverde> or at least pure factorizing [01:47:00] <saintdev> yeah, it is that's already a separate patch [01:48:24] <saintdev> it was just easier to do git diff origin, than to specify a range [04:53:57] <peloverde> saintdev: cool [05:01:24] <peloverde> If you want to git send-email that and any of the other patches that are cosmetic or otherwise split out, it would be appreciated [05:28:47] <kierank> any idea if v210 can be SIMDed? [06:09:38] <spaam> God morgon :D [06:10:15] <kshishkov> god morgon [06:12:32] <pJok> god morgon [06:13:12] <kierank> hello [06:13:21] <kierank> top of the morning to you [06:13:56] <thresh> moroning [06:33:04] <Sean_McG> happy $TIMEZONE [06:44:18] <cartman> moin [06:44:50] <spaam> hey cartman. where is kenny? [06:45:01] <cartman> bastards killed him [06:45:10] <spaam> :( [06:45:22] <spaam> time to get to work .. bbl :) [06:45:27] <cartman> see ya [06:51:03] <saintdev> wow: ffmpeg -y -i ~/codecs/samples/comp.wav -strict experimental -acodec aac -ab 128k ~/test.mp4 [06:51:44] <saintdev> sounds ok [06:52:41] * saintdev needs new headphones [07:10:30] <divVerent> ffmpeg API "hint"... [07:10:48] <divVerent> av_rescale_q(av_rescale_q(x, LARGETIMEBASE, SMALLTIMEBASE), SMALLTIMEBASE, LARGETIMEBASE) == x [07:10:54] <divVerent> as long as LARGETIMEBASE >= SMALLTIMEBASE [07:11:00] <divVerent> this is currently true, but can I rely on this staying true? [07:11:13] <divVerent> (it follows mathematically from the round-to-nearest mode) [07:12:04] <divVerent> to prove this, simply disprove >= x+1 and <= x-1 ;) [07:12:49] <divVerent> I need this in my code to ensure both unique stream and codec timestamps to prevent encoding errors [07:13:12] <divVerent> my current code basically does frame skipping etc. based on the "worse" of the two time bases, and rescales to the other [07:14:07] <divVerent> and in case the worse time base is the stream time base, I have to rescale stream pts to codec pts before avcodec_encode_video, and rescale codec pts back to stream pts to feed libavformat from coded_frame [07:14:20] <divVerent> and this is where my assumption comes in [07:16:20] <divVerent> one case where this comes in is Matroska BTW... Matroska's timebase is milliseconds, and I need this "convert back and forth is fine" assumption in case the codec time base is better than 1000fps [07:24:12] <divVerent> the assumption is OBVIOUSLY true if codec time base divides the stream time base... but my question is: in the current implementation I can rely on the assumption, can I in the future? [07:33:46] <Tjoppen> why not use rational numbers? [07:40:15] <divVerent> because the pts field in AVFrame doesn't want them [07:40:39] <divVerent> basically, I have to ensure that the pts fed to libavcodec are monotonous [07:40:44] <divVerent> and the pts fed to libavformat are unique [07:41:16] <divVerent> so my only way is to already restrict the ones I pass to libavcodec [07:41:28] <divVerent> as I there is no direct correspondence between the frame fed into libavcodec, and the output [07:50:43] <spaam> mmm kall trocadero [07:54:52] <Tjoppen> ruggles: got some samples for you [07:56:12] <Tjoppen> if I put them on the ftp, can we get them up on samples.mplayerhq? [08:00:22] <kierank> samples of what? [08:00:44] <Tjoppen> lxf [08:00:59] <Tjoppen> one with 20-bit pcm, which is what ruggles is after [08:01:19] <kierank> lxf? [08:01:24] <kierank> or mxf? [08:02:12] <Tjoppen> lxf, yes [08:02:35] <kierank> never heard of that one [08:03:42] <Tjoppen> neither had I, nor had most of the internet. I managed to reverse engineer it [08:04:02] <Tjoppen> it's output by some broadcast gear made by harris [08:08:37] <spaam> whyyy cartman why ? [08:09:12] <cartman> spaam: I don't own a Mac :) It was given to me due to my current work [08:09:45] <spaam> cartman: you dont have to give it back? just say you d [08:09:48] <spaam> did that [08:10:12] <cartman> spaam: this is a special built 2.66 Core i7 device, costs ~3000$ [08:10:16] <cartman> they won't donate me that [08:10:42] <spaam> who said about donate? you can borrow it for loooong time :) [08:10:46] <cartman> LOL [08:10:53] <cartman> not here :) [08:12:18] <cartman> I hope they will let me "borrow" the Nexus1 though [08:14:45] <spaam> that is a old phone.. why whould they get that back? :) [08:15:06] <cartman> spaam: I am asking myself the very same question :P [08:15:18] <cartman> I need more generous $BOSS [08:45:44] <av500> gm [08:46:28] <kierank> hello [08:47:34] <cartman> av500: back from holiday? [08:49:19] <kshishkov> cartman: nope, that was work, now to holiday in Darmstadt office :) [08:49:40] <cartman> kshishkov: ah [08:49:46] <kierank> kshishkov: where did av500 go? bangalore? [08:49:47] <cartman> slacking as usual [08:50:27] <av500> cartman: yep [08:53:25] <kshishkov> kierank: do you want to visit Bangalore yourself? [08:53:37] <av500> kierank: I was there: http://maps.google.com/maps?f=q&sll=37.0625,-95.677068&sspn=70.0649,114.257812&ll=47.250721,11.939156&spn=0.001883,0.003487&t=h&z=19 [08:53:54] <kierank> kshishkov: no but I thought av500 was the outsourcing expert [08:59:22] <kshishkov> lol - http://stbit.ru/index.php?option=com_content&view=article&id=5&Itemid=4&lang=en <- if there weren't enough Russian wavelet-based codecs [09:00:13] <thresh> ты просто завидуешь [09:00:28] <kshishkov> ага, щазз [09:01:12] <kshishkov> помнится, знакомый профессор говорил: "не берись за вейвлеты, ими китайцы занимаются" [09:31:00] <saintdev> peloverde: you there? [09:31:08] <peloverde> pong [09:31:29] <saintdev> i caught a bug in bit demand calculation [09:32:09] <saintdev> ctx->frame_bits + size - bits [09:32:34] <saintdev> if the actual number of bits used is much greater than size, this goes negative [09:32:42] <saintdev> giving us a negative desired PE [09:32:50] <peloverde> ok [09:33:07] <peloverde> I thought I saw a check for that somewhere [09:33:11] <kshishkov> sounds very true to life [09:33:14] <peloverde> maybe it was something else [09:33:28] <saintdev> not sure how to fix it, because we need "the actual number of bits in the bitreservoir" [09:34:23] <peloverde> can you repost the url? [09:35:00] <saintdev> let me paste a new one, because i changed the initialization for bitres [09:35:06] <peloverde> ok [09:36:22] <peloverde> I hate that windows is so ununixy [09:36:29] <saintdev> peloverde: http://pastebin.com/rfpQh0y9 [09:38:00] <saintdev> afaikt what 3gpp does is "min(bit_factor, 1 - 0.3 + bitres_bits / frame_bits)" [09:38:29] <saintdev> which doesn't seem to have any logic to it that i can spot [09:38:47] <saintdev> and i refuse to put something i don't understand in, just because 3gpp does it [09:39:28] <peloverde> are we talking about near line 104 of the patch? [09:40:13] <saintdev> erm, line 104 is the modifications to AacPsyCoeffs... [09:40:43] <peloverde> I mean 148 [09:40:54] <peloverde> but I guess taht is init [09:41:02] <saintdev> that's the initialization of the bitres. [09:41:18] <saintdev> 226-256 is calculation of bit demand [09:41:18] <peloverde> int calc_bit_demand()? [09:41:22] <saintdev> yes [09:42:12] <saintdev> so for line 255 3gpp does: [09:42:50] <saintdev> return FFMIN(ctx->frame_bits * bit_factor, ctx->frame_bits * (1 - 0.3 + bits / ctx->frame_bits)) [09:44:49] <saintdev> ...which still leads to an infinite loop, wth [09:45:14] <saintdev> only this time desired pe is positive [09:47:49] <saintdev> maybe it's because of where i set bitres bits = frame_bits [09:48:54] <saintdev> ok, maybe that wasn't the issue... [09:49:52] <saintdev> i still see negative pe being an issue, because then it will attempt to zero every band. [09:50:39] <peloverde> What about section 5.6.4 Out of Bits Prevention? [09:51:37] <saintdev> that should happen in quant [09:52:41] <saintdev> psymodel ends at 5.6.1. 5.6.2+ is all quant [09:53:32] <peloverde> yes, but this bit demand being negative is a result of quant using too many bits, no? [09:53:54] <saintdev> which is fine, as we're using bits from the bit resevoir [09:55:17] <saintdev> or rather we _sould be_ using bits from the reservoir [09:55:49] <peloverde> But if 'bitreservoirBits' is negative doesn't that men we have used bits that aren't in the reservior? [09:58:14] <saintdev> i guess maybe this is where we need to reduce min snr, and allow more holes [09:59:56] <saintdev> ...or maybe not... [09:59:58] <saintdev> pe = 9.377437, desired = 3600.179932 [10:03:10] <saintdev> although obviously quant is having trouble fitting everything in one frame [10:04:09] <kshishkov> well, IIRC when file had a second of silence at the beginning it was even funnier [10:05:15] <saintdev> well i have a file with a lot of silence at the beginning (not sure exactly how long it is), but it handles that just fine. [10:06:01] <saintdev> it just seems to loop forever if it starts to go way over it's allocated bits [10:07:14] <saintdev> well i think i'm going to come back to this tomorrow, can't think right now. [10:07:32] <saintdev> i really don't want to have to rework quant...yet [10:16:13] <spaam> which version of gcc did came with -march=native ? :) [10:19:03] <kierank> google says 4.2 [10:19:52] <spaam> Nice [10:20:31] <spaam> then i can use it with portage on my macbook pro :) [10:21:49] <kshishkov> huh, so gcc couldn't produce native code before 4.2? [10:22:32] <Flameeyes> kshishkov: -march=native is "auto-tuning" [10:23:01] <lu_zero> kshishkov: -march=native is -march=guess-what-are-you-running-on [10:23:15] <cartman> uses rand() [10:23:25] <kshishkov> and pleases Gentoo users [10:23:28] <kierank> cartman: rand() produces a major improvement [10:23:47] <Flameeyes> it's more or less the same as -march=$yourcpu plus parameters' tweaking based on cache size of the currently-used CPU [10:24:04] <lu_zero> kshishkov: so they don't have to guess for themselves what's their cpu [10:24:08] <Flameeyes> not fantastic, but makes it easier to share the same _configuration_ between two hosts [10:25:06] <kshishkov> lu_zero: laaaaame [10:25:11] <peloverde> -march=core2 ought to be good enough for anybody [10:25:56] <kshishkov> not on my Cortex-A8 [10:26:07] <peloverde> fair enough [10:26:24] <cartman> -march=coretexa8 :p [10:27:29] <kierank> -march=placebo [10:27:30] <JEEB> I remember -march=i386 making faster binaries than core2 the last time marcan tested it :3 [10:28:00] <kierank> -march=placebo -mtune=grain [10:29:06] <spaam> :) [10:29:45] <kshishkov> kierank: -mtune=benny-lava [10:30:34] * kierank googles that [10:31:22] <kierank> I don't get it [10:31:28] <kshishkov> http://www.youtube.com/watch?v=ZA1NoOOoaNw [10:32:20] <kierank> yeah but what's that got to do with -mtune? [10:32:22] <peloverde> JEEB: that seems off seeing as i386 lacks sse2 and every benchmark I've seen has scalar sse2 kick x87's ass [10:32:59] <kierank> kshishkov: at least mine was a reference to x264 [10:33:01] <kshishkov> kierank: it's quite fine tune. And words make little sense (like GCC tuning) [10:33:17] <kierank> ah [10:34:04] <JEEB> peloverde, yes -- by all marks it _seems_ off, I'll have to see if I have the things he tested it with still somewhere in my browser's memory [10:35:10] <peloverde> I think if -O3 is on -ftree-vectorize is on which is generally terrible [10:36:15] <peloverde> i386 shouldn't generate bad vector code because i386 lacks vector instructions [10:47:54] <iive> it's kind of strange, i386 doesn't issue cmov and in theory should increase mispredictions a lot. i686 should issue cmov and not turn on sse by default. [10:49:07] <Flameeyes> iive: are you sure i686 turns on cmov? [10:49:26] <iive> yep [10:50:11] * av500 wonders if it's wise to read the -devel backlog before lunch [10:51:02] <kshishkov> av500: nothing special there, just filter out usual flames [11:31:33] <kierank> anything look wrong with this get buffer implementation: http://pastebin.com/Q05nP9VC [11:33:32] <mru> would you be asking if there wasn't? [11:33:52] <kierank> no [11:36:32] <mru> the pic->age value looks wrong [11:36:40] <mru> I have no idea what it means [11:36:55] <mru> but I had to duplicate the magic from default_get_buffer() to make it work [11:37:39] <iive> sequential number used to skip mc if the data hasn't changed [11:38:02] <mru> it's not documented [11:38:08] <mru> and totally nonobvious what it does [11:38:46] <mru> cartman: you're friendly with clang, right? [11:38:51] <kierank> avcodec.h says "Set to INT_MAX if the buffer has not been used yet." [11:39:05] <cartman> mru: for some definition of "friend", yes [11:39:26] <mru> cartman: any idea if backends other than x86 and arm are expected to work at all? [11:39:45] <mru> I get "error: unable to interface with target machine" when trying to cross-compile to anything else [11:39:48] <cartman> mru: the answer would be no, afaik [11:39:53] <mru> and segfault when running natively on ppc [11:40:06] <cartman> ppc one should be reported probably [11:40:20] <cartman> but Apple i [11:40:24] <cartman> is dropping PPC support [11:40:32] <cartman> so I wouldn't be surprised [11:40:46] <mru> and the mips backend looks like a complete joke [11:40:56] <cartman> some of them are toys afaik :) [11:42:53] <Kovensky> 08:40.20 cartman: but Apple is dropping PPC support <-- finally? [11:43:09] <kierank> hehe even vlc doesn't know what to do with age [11:43:32] <cartman> Kovensky: in 10.7 yeah [11:43:46] <Kovensky> wasn't 10.6 intel-only btw? [11:43:56] <mru> they have ppc emulation iirc [11:43:59] <cartman> Kovensky: true but it supported PPC emulation [11:44:03] <Kovensky> oic [11:44:14] <Kovensky> it isn't installed by default though [11:44:16] <cartman> no moar ppc for you [11:44:33] <Kovensky> I don't even know why I installed Rosetta, it's not like I have any PPC apps [11:44:38] <Kovensky> lul [11:44:54] <cartman> Kovensky: got MS Office? [11:45:04] <Kovensky> pirated 2011 [11:45:25] <cartman> possibly it installed Rosetta [11:45:27] <cartman> I think [11:45:45] * cartman pets his valid M$ licenses [11:45:52] <Kovensky> well, I installed Rosetta myself on the custom install options for OSX's setup =p [11:46:13] <Kovensky> my OSX doesn't have a valid license either =p [11:46:18] <Kovensky> >10.6.3 iso from tpb [11:46:19] <cartman> bah [11:46:22] <Kovensky> >installed on non-apple hardware [11:46:48] <cartman> I bet you pirate ffmpeg too!!111!! [11:46:56] <Kovensky> hah [11:47:54] <mru> why would anyone voluntarily install osx? [11:48:14] <Kovensky> I wanted a unix with a non fucked up GUI [11:48:29] <mru> so fail on both accounts [11:48:48] <pross-au> why would anyone voluntarily wear a turtle neck sweater [11:48:58] <mru> they cause cancer [11:50:19] <Kovensky> 08:48.30 mru: so fail on both accounts <-- how so? it's a unix, and the GUI isn't like X's clusterfuck of incompatible and mostly ugly GUI toolkits [11:50:51] <mru> mach is not a unix [11:51:12] <mru> the true unixes are sysv and bsd and their derivatives [11:51:31] <Kovensky> didn't apple pass mach through SUS [11:51:39] <Kovensky> the SUS certification that is [11:51:43] <mru> macos is a conglomerate of microkernel with bits of bsd and some homebrew stuff bolted on in a haphazard fashion [11:51:54] <cartman> it works ;> [11:51:57] <mru> I disagree [11:52:41] <cartman> I'll format this Mac soon and give it away, so I'll agree this time :P [11:52:45] <lu_zero> 12:47 < Kovensky> I wanted a unix with a non fucked up GUI [11:52:56] <lu_zero> I'd debate on the gui part [11:53:22] <mru> osx may pass the certification tests, but it's not a unix in spirit [11:53:23] <lu_zero> regarding the "unix" I'd say that Haiku is as unix as macosx... [11:53:46] <cartman> Mac is eyecandy and some people love that [11:54:05] <cartman> I'd be happy if Linux just provided ClearType like font rendering, rest is useless for me [11:54:26] <mru> I'm quite happy with my 8-point non-aa fonts [11:54:29] <av500> cartman: you need cleartype for 5x7 fonts? [11:54:30] <Kovensky> 08:52.57 lu_zero: I'd debate on the gui part <-- I'm not arguing that Aqua is prettier than everything else; I'm arguing that it at least is consistent [11:54:35] <cartman> av500, mru bah [11:54:56] <mru> consistently annoying [11:55:07] <cartman> neeed better font rendering [11:55:29] <Kovensky> mru: as opposed to X, which is inconsistently consistently annoying [11:55:43] <elenril> >itt people having no clue what X is [11:56:00] <mru> what elenril said [11:56:07] <cartman> X [11:56:15] <cartman> X & Y comes with Math. :p [11:56:15] * Kovensky sees a bikeshed [11:56:28] <pJok> mru, don't forget a lot of NeXT stuff [11:56:31] * cartman paints it black [11:57:25] <pJok> i see a bikeshed and i want to paint it black? [11:57:49] * pJok thinks that the song from Rolling Stones originally was about bikesheds [11:58:03] * mru was thinking about that song too [11:58:43] <lu_zero> Kovensky: having used it I must say that Aqua is as inconsistent as other toolkits... [11:58:46] <av500> "... I see the votes go by..." [11:58:53] <lu_zero> that said [11:59:47] <lu_zero> is there a particular reason why mpegts isn't outputting the fake teletext data I'm putting? [12:00:03] * lu_zero inspected the generated file and the data is there... [12:00:05] <pJok> mru, friend of mine was looking around at itunes, found some 20 year old api references [12:00:28] <av500> pJok: iturns20 [12:00:55] <kierank> lu_zero: do you write the correct descriptors [12:00:58] <pJok> i think it was Quartz [12:03:02] <lu_zero> kierank: good question [12:03:07] <lu_zero> I hacked it up [12:03:35] <kierank> until there's a descriptor it's just private data [12:04:14] <lu_zero> http://ffmpeg.pastebin.com/mYYntQY6 [12:04:26] <lu_zero> kierank: private data would be fine as well [12:04:38] <lu_zero> (given that it would be outputted) [12:04:52] <Kovensky> 08:58.44 lu_zero: Kovensky: having used it I must say that Aqua is as inconsistent as other toolkits... <-- I wasn't referring to internal inconsistency (which is mostly unseen on most software, at least software that I've used), the main annoyance I have with software that targets X is that there are so many toolkits to chose from [12:04:57] <Kovensky> Tk, GTK, FLTK, wx, Qt, Swing, and if you run anything that doesn't use the same toolkit as everything else you're running it will instantly look out of place, even if you have a theme design to emulate another toolkit [12:05:03] <Kovensky> +ed [12:06:56] <elenril> ....choose programs using the same toolkit if you care so much? [12:07:21] * pJok hands Kovensky the bikeshed and paint [12:07:47] <Kovensky> elenril: doesn't make the issue go away, and you don't always have a choice [12:08:11] <Kovensky> (other than TakingTheThirdOption of not using it at all, but that's silly) [12:08:36] <mru> and on osx it doesn't exist at all then [12:09:51] <Kovensky> it exists, but is rather rare [12:10:20] <Kovensky> in 4 months of using osx I've only encountered pcsx2, desmume and wireshark that don't follow the interface [12:10:53] <Kovensky> well, and jdownloader, because it insists in using custom swing skins, and clementine, for being a not-so-good qt4 port of amarok [12:11:16] <mru> on X11 you get a choice of sticking with one toolkit for consistency or using whatever apps work best regardless of look [12:11:24] <mru> on osx you only get one choice of toolkit [12:11:36] <mru> so the apps using other toolkits are simply not available [12:12:12] <Kovensky> pcsx2, desmume and wireshark all use gtk [12:12:22] <Kovensky> with the fucking ugly raleigh theme <_< [12:12:39] <Kovensky> clementine uses qt4-aqua [12:12:50] <elenril> can i have some reviews for avio_get_str? [12:47:39] <mru> elenril: is skip(n) any different from seek(n, SEEK_CUR)? [12:48:45] <kshishkov> maybe in behaviour over non-seekable streams [12:50:07] <mru> that would be crazy [12:50:15] <mru> I think skip should be replaced with seek [12:50:33] <kshishkov> made into macro? [12:50:34] <mru> and seek updated to handle non-seekable streams in that special case if necessary [12:51:58] <elenril> only in return value it seems [12:52:46] <elenril> seek returns new position or error, skip returns 0 or error [12:53:53] <elenril> fun fact: seems the return value isn't used anywhere [12:54:12] <kshishkov> of course [12:55:06] <kshishkov> reminds me of one of paranoic definitions - always checks if file was closed successfully [12:55:15] * av500 skips elenril [12:55:39] <hyc> well, close() can fail on NFS [12:56:05] <Flameeyes> hyc: and how do you recover from that? [12:56:20] <hyc> no way I know of [12:56:26] <mru> hyc: and many other ways [12:56:44] <Flameeyes> so the question is: "why testing an error at all if you cannot recover from it?" [12:56:55] <mru> you may not be able to recover, but alerting the user that something went wrong is still nice [12:57:00] <hyc> you can re-open and re-write [12:57:44] <av500> hyc: if you still have the data [12:58:08] <av500> which at the time you call close() you might not have [12:58:30] <hyc> true [13:04:29] <BBB> kshishkov: any progress? [13:05:02] <BBB> kshishkov: ref decoder does weird frame ordering also, looks really weird, as if the bitstream itself )or the encoder) is broken [13:05:18] <kshishkov> BBB: so you can't accuse me [13:05:27] <BBB> well [13:05:32] <BBB> did you look at it? [13:05:59] <kshishkov> nope, your message was soothing [13:06:04] <BBB> hm... [13:06:24] <kshishkov> if ref decoder does the same then it's right by definition [13:06:28] <kierank> BBB: you'd probably know the answer to why this is broken: http://pastebin.com/Q05nP9VC [13:07:39] <BBB> nope [13:07:54] <kierank> :/ [13:12:13] <BBB> sorry, I'm not familiar with the get_buffer stuff [13:12:42] <kshishkov> and why not just compare it to default implementation [13:12:57] <kierank> because default implementation does a ton of bizzare things [13:15:17] <kierank> I'm starting to think libavutil might be broken [13:15:31] <kshishkov> :) [13:17:25] * kierank doesn't want to give in and use memcpy [13:50:18] <DonDiego> kshishkov: what's the point you see in keeping sonic? [13:57:39] <lu_zero> DonDiego: it's an interesting codec IMHO [13:57:56] <lu_zero> yet would be nice implementing CELT [13:58:05] <mru> it's not interesting if it doesn't work [13:58:18] <DonDiego> i don't doubt it, but ffmpeg is not the place to carry interesting experimental research codecs [13:58:41] <DonDiego> not in the master branch that is, people are of course welcome to play with them in priv branches [13:58:54] <mru> on that note, how about dropping snow? [13:59:11] <DonDiego> same sentiment from my side [13:59:28] <merbzt> snow works [13:59:37] <merbzt> sonic doesnt [13:59:37] <mru> perhaps [13:59:43] <DonDiego> snow may even have a few samples in our collection, but i see little point in it also [13:59:58] <mru> snow is still an abandoned, experimental codec [14:00:04] <merbzt> same as with alot of game formats [14:00:04] <DonDiego> it's also one huge drop of monolithic mn-style code... [14:00:10] <merbzt> should we drop them also ? [14:00:19] <DonDiego> game formats are used in the wild [14:00:26] <DonDiego> and samples exist [14:00:43] <elenril> well there are people playing with snow [14:00:44] <merbzt> snow samples exist also [14:01:22] <merbzt> just mark snow as experimental if it isn't already [14:01:47] <DonDiego> of course there are people playing with it - so? nobody doubts that people out there are doing codec research [14:02:03] <DonDiego> but mainline ffmpeg is not the place to carry such stuff, much less indefinitely [14:02:10] <mru> snow uses lots of dubious programming practices that are hard to fix [14:02:22] <kshishkov> mru: and wavelets! [14:02:26] <DonDiego> same applies to nut really - it never made it past the toy stage [14:02:28] <lu_zero> snow is still good [14:02:36] <lu_zero> DonDiego: I'm using nut in production... [14:02:43] <lu_zero> please let it be ^^; [14:02:49] <DonDiego> glad to hear that [14:02:53] <DonDiego> which implementation? [14:02:56] <mru> nut can stay [14:02:58] <lu_zero> ffnut [14:03:04] <av500> nutjobs.org [14:03:09] <DonDiego> last i talked to ods15 about it libnut and ffnut disagreed [14:03:15] <mru> it's not a huge burden, and it's useful for regression testing [14:03:30] <elenril> snow is a huge burden? [14:03:35] <lu_zero> and I think snow should stay till we get dirac or jpeg2k [14:03:47] <DonDiego> snow takes ages to compile [14:03:53] <lu_zero> then we could reconsider it [14:04:17] <Flameeyes> saste: which ld version are you using? [14:04:33] <lu_zero> DonDiego: the next code in we could ask help to document both [14:05:02] <kshishkov> DonDiego: I've just tried encoding and decoding Sonic-in-NUT and it worked fine [14:05:11] <saste> Flameeyes: GNU ld (GNU Binutils for Debian) 2.20.1-system.20100303 [14:05:25] <Flameeyes> saste: uhm... funny [14:05:43] <Flameeyes> I wonder if Debian patched it up [14:07:25] <kshishkov> DonDiego: Sonic in .mkv works fine too [14:08:08] <lu_zero> where is broken then? [14:09:02] <DonDiego> it's still just a toy, what's the point of it? [14:09:24] <DonDiego> saste: i think you have a bunch of patches for me to review, could you point me at some of them? [14:09:29] <lu_zero> DonDiego: same could be said with vorbis before the atouv effort [14:09:48] <kshishkov> DonDiego: it give us two audio codec in stats [14:10:41] <lu_zero> and I think that experimental codecs are good to show and test the ffmpeg as codec toolkit [14:11:05] <saste> DonDiego: Add detail to the documentation for ffmpeg -map [14:11:39] <saste> then there are the filters which have been already pushed to videolan [14:12:41] <saste> nut is useful... it's the only format which supports rawvideo with all the supported ffmpeg pixel formats [14:12:57] <mru> yes, nut is useful for such reasons [14:12:58] <lu_zero> among the rest [14:13:40] <DonDiego> very well, nut topic closed then, that leaves snow and sonic :) [14:13:49] <elenril> let's vote! [14:13:53] * elenril ducks [14:14:09] <kshishkov> DonDiego: they are featured codecs for NUT [14:14:09] <saste> on the other hand... snow is interesting from the research point of view [14:14:12] <DonDiego> better - let's vote *right away* before discussion... [14:14:32] <saste> maybe a good idea would be to fund more work on it.. it was proposed some years ago and then discarded [14:14:47] <saste> at that time there was a guy which was willing to fund it [14:14:55] <saste> at least in part (2k iirc) [14:15:19] * elenril recalls Dark_Shikari claiming that wavelets are doomed [14:15:29] <mru> they are [14:15:56] <Dark_Shikari> if you want to do a research codec, go work on that CELT/lapped DCT hybrid codec thing. [14:16:14] <kshishkov> especially if you want research video codec [14:17:02] <saste> Dark_Shikari: i have no serious knowledge related to DSP/codec compression technology [14:17:11] <saste> Dark_Shikari: so my opinion doesn't count [14:19:32] <lu_zero> wavelets are different, so different problems and different solutions [14:19:46] <lu_zero> still I liked a lot the lift optimizations =p [14:20:19] <lu_zero> regarding celt it looks really promising [14:20:40] <Dark_Shikari> The only "CELT-like" part of the lapped DCT thing is just the separate energy/shape coding [14:22:02] <lu_zero> Dark_Shikari: are you willing to mentor a summer of code to have an initial toy about it? [14:22:23] <Dark_Shikari> There's already a WIP prototype by the xiph guys that is busy not being worked on [14:22:37] <DonDiego> saste: your patch or the ones sent by mike scheutzow? [14:23:12] <saste> DonDiego: i addressed some of the issues raised by BBB [14:23:31] <saste> DonDiego: so the last patch of the thread [14:26:56] <lu_zero> Dark_Shikari: would make sense being re-implemented on ffmpeg? [14:27:21] <Dark_Shikari> It's still hacky research stuff, dunno [14:33:46] <CIA-15> ffmpeg: Mans Rullgard <mans@mansr.com> master * r00ba041cb3 ffmpeg/configure: [14:33:46] <CIA-15> ffmpeg: Use --sysroot flag for clang [14:33:46] <CIA-15> ffmpeg: Although not documented, clang does support the --sysroot flag, and it [14:33:46] <CIA-15> ffmpeg: does the right thing. Use this flag intead of -isysroot which only [14:33:46] <CIA-15> ffmpeg: applies to header file searches, not the linker. [14:33:47] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans@mansr.com> [14:34:09] <ruggles> the description of Bonk, which Sonic is based on, sounds very similar to wavpack lossy but without the lossless correction data. nothing about it looks particularly cutting-edge compared to anything being done today. [14:34:55] <mru> bink version o = bonk? [14:35:21] <kshishkov> ruggles: look at the date ;) [14:35:40] <kshishkov> mru: no, 'twould be Australian Binko [14:35:57] <ruggles> 2001 [14:37:06] <ruggles> i suppose that was pretty experimental in '01. but why should we try to imitate it now? or fix our broken imitation? [14:37:42] <kshishkov> why do you call it broken? [14:37:57] <ruggles> it doesn't work for me. [14:38:04] <kshishkov> it does for me [14:38:39] <mru> sonic.c has had exactly one non-cosmetic/maintenance commit [14:38:52] <kshishkov> initial? [14:38:54] <mru> yes [14:39:01] <mru> that was in 2004 [14:39:24] <mru> just kill it [14:39:32] <mru> it is clearly nothing but a maintenance burden [14:41:21] <lu_zero> with a message like [14:41:23] <ruggles> kshishkov: hmmm it does seem to be working now. i don't know why it didn't work for me before. [14:41:35] <lu_zero> "superceeded by wavpack" ? [14:41:47] <kshishkov> ruggles: maybe it was shy? [14:42:02] <ruggles> ah, that's it. doesn't support 48kHz but doesn't fail. [14:42:28] <lu_zero> if it is working I'd rather have it preserved or ask first if somebody would have interest on it [14:43:08] <lu_zero> otherwise I'd just add a branch for it called historic [14:45:44] <ruggles> i'm not interested in it, but i'm ok with keeping it around. maybe flag it as experimental though. [14:46:23] <kshishkov> definitely [14:48:13] <mru> nobody is every going to touch it again, much less use it [14:48:18] <mru> -y [15:05:05] <kshishkov> it's the only hybrid lossy/lossless encoder we have [15:05:39] <spaam> does sonic work ? [15:05:43] <kshishkov> yep [15:06:57] <spaam> then why remove it if it still work ? why do files need love every year? :) [15:07:05] <lu_zero> then might be worthy as foundation [15:07:09] <kshishkov> because API changes [15:07:29] <lu_zero> kshishkov: anything could be used to implement a wp encoder? [15:07:33] <ruggles> i fixed the sample rate issue. it's a bug. but a simple one. i'll send a patch. [15:08:01] <kshishkov> lu_zero: yep, original BSD-licensed WavPack sources should do [15:08:10] <kshishkov> lu_zero: and ruggles for implementor ;) [15:10:03] <ruggles> there is a lot on my plate, but if a wavpack encoder would be wanted by enough people and the foundation would provide enough money, i would definitely consider doing it after i finish ac3. [15:11:33] <spaam> ruggles: how much work is left on ac3? :) [15:11:55] <lu_zero> ruggles: sounds like a plan =) [15:12:04] <ruggles> spaam: maybe a month if i'm lucky. 2 months if i'm not. [15:12:48] <spaam> ruggles: ok :) not that far away then :) [15:18:45] <DonDiego> spaam: for some reason code rots if you don't touch it - never noticed how it gets uglier on its own from year to year? [15:19:14] <kshishkov> DonDiego: it's just the rest of environment improving [15:19:56] <kshishkov> DonDiego: so for enterprise code it's the other way round - while other code gathers ugly hacks that one stays clean and nice looking fresh from India [15:48:59] <astrange> why do we need a wavpack encoder if flac exists? [15:49:44] <merbzt> the hybrid thingy [15:49:54] <merbzt> but I don't really see the point either [15:50:02] <mru> dts-hd or whatever variant [15:50:33] <Tjoppen> meh. just add a lossy option to the flac encoder [15:50:35] <mru> but there's nothing inherently good about a hybrid design [15:50:53] <kshishkov> astrange: and I heard that WV has better 7.1 support than Flac [15:51:10] <mru> the _only_ reason to use a hybrid codec is for adding an optional lossless layer to an existing lossy codec [15:51:31] <astrange> http://wiki.hydrogenaudio.org/index.php?title=Lossywav [15:52:06] <kshishkov> mru: for DTS-HD it's DCT codec + lossless residue, for WavPack and Sonic it's the same compression algorithm but with lossy coding of prediction errors [15:52:29] <mru> and what's the point? [15:52:36] <mru> does it gain anything other than complexity? [15:52:52] <kshishkov> it has almost no overhead [15:53:10] <kshishkov> and lossy part doesn't feature usual DCT artifacts [15:53:38] <ruggles> put the lossy part on your portable media player? i actually have one that supports wavpack. [15:54:30] * av500 has a portable media player with a 500GB hard drive [15:54:39] <ruggles> ...but i still use separate flac & mp3 files [15:58:12] <ruggles> only somewhat important benefit i can see is to reduce storage complexity. avoid having 2 sets of files (and metadata) for lossless and lossy. but there are other more standardized solutions like mpeg4-sls. [16:29:46] <kshishkov> well, I'd mourn Sonic for a few nanoseconds if you remove it [16:37:54] <in3xes> while demuxing, ffmpeg doesn't process audio and video packets differently? Both are just packets right? [16:41:08] <Tjoppen> well, there's parsers. and things like the dv demuxer which treats audio a bit special [16:42:42] <ruggles> in3xes: depends on the format too. The demuxer creates the packets, so it might have to do different things to create audio vs. video packets. [16:43:38] <Tjoppen> "it depends" [16:45:02] <in3xes> Okay. [16:46:07] <in3xes> Then how a parser finds whether a chunk of data is audio or video? [16:46:40] <av500> ffplay.c [16:47:01] <av500> well, the demuxer knows that from the file format it demuxes [16:47:01] <Tjoppen> the demuxer says what codec each stream is, and may or may not elect to use a parser per stream [16:47:32] <av500> in3xes: what are you after? [16:48:18] <in3xes> right now, for vivo demuxer, but in general for knowledge... [16:51:03] <in3xes> So, each stream needs different codec to decode it, basically audio and video are different streams...right? [16:52:06] <twnqx> right [16:54:03] <in3xes> I am a bit confused about how streams and packets are linked, can anyone enlighten me? Please? [16:54:45] <twnqx> umm multiple packets form a stream? [16:55:37] <av500> in3xes: audio and video has frames [16:58:01] <in3xes> av500: each frame is a packet? [16:59:43] * in3xes feels dumb :-| [17:00:22] <ruggles> in3xes: usually yes. but there are some cases where the demuxer can't determine where frames start/end so a separate parser is required to separate the series of packets into a series of frames. [17:00:27] <av500> in3xes: yes, in most containers [17:01:10] <av500> in3xes: just imagine you are given 2 series of audio and video frames, how would you "package" them? [17:01:44] <mru> chop them up into tiny pieces and throw them in a pan with some oil [17:01:45] <in3xes> one after after another mentioning size and type of each frame? [17:02:06] <in3xes> OH [17:02:09] <av500> in3xes: you just invented a simple muxer [17:02:13] <av500> e.g. .flv [17:02:32] <av500> add the timestamp and you are done [17:02:55] <in3xes> Okay [17:03:04] <ruggles> mru: making me hungry... time for lunch [17:03:24] <av500> ruggles: go eat some audio packets then [17:04:11] <mru> mpeg stir fry, yummy [17:04:17] <in3xes> One last question: Why is the max_stream number is 20? [17:04:35] <mru> it won't be for long [17:04:59] <av500> in3xes: because nobody will needs more then 20 streams, ever [17:05:02] <Tjoppen> the limit will be removed in the next minor bump [17:05:05] <Tjoppen> (right?) [17:05:09] <Tjoppen> *major [17:05:11] <mru> yes [17:05:26] <in3xes> I mean, why not just 2? [17:05:45] <bilboed-pi> multi-audio files [17:05:50] <Tjoppen> and subtitles [17:05:56] <in3xes> Oh, Okay [17:05:57] <Tjoppen> and "data" stream. etc [17:05:59] <av500> and album art [17:06:09] * bilboed-pi slaps in multiplexed mpeg-ts just for kicks [17:06:20] <Tjoppen> yes, ts can have hundreds [17:06:32] <Tjoppen> hell, even avi supports 100 streams [17:06:33] <mru> 1<<13 give or take [17:06:37] <av500> we should make stream_count a float [17:06:49] <bilboed-pi> mru, 0x1fff can't be used [17:06:54] <mru> that's the take [17:06:58] * bilboed-pi nods [17:07:00] <mru> and 0 is reserved for pat [17:07:03] <mru> and pmt needs one [17:07:13] <mru> so (1<<13)-3 [17:07:23] <mru> dvb reserves a bunch more too [17:09:52] <in3xes> Thank you all :) [17:24:54] <astrange> http://astrange.ithinksw.net/clang/ffmpeg/ ran out of curiosity [17:25:17] <astrange> the logic errors are all noise that's not worth reading, but dead code might be worth something [17:34:22] <peloverde> Some of the "This statement is never executed" seem strange [17:34:41] <mru> totally outrageous is more accurate [17:35:04] <astrange> i think i'd just ignore everything it says that involves a loop [17:35:19] <mru> ok, there goes 102% of the code [17:35:41] <peloverde> at least the general logic errors are generally related to variables that are technically mutable but don't change across multiple loop passes [17:49:06] <ods15> 16:03:09 <@DonDiego> last i talked to ods15 about it libnut and ffnut disagreed [17:49:22] <ods15> wow, i don't remember at all what the discrepencies are... [17:50:00] <ods15> I do remember for certain that I kept "nut_version 2" in libnut to force it to be non-compliant, and the spec says that the only supported version is 3... [17:50:37] <mru> my /dev/random disagrees with yours [17:50:59] <ods15> :) not sure what you meant there [17:51:10] <ods15> i usually use /dev/urandom anyway :P [17:51:18] <mru> you mentioned a spec... [17:51:31] <mru> I find /dev/random easier to understand [17:51:36] <ods15> well, do you consider ffnut to be /dev/random ? [17:52:04] <av500> [vc1 @ 0x8098360]Interlaced WVC1 support is not implemented [17:52:09] * av500 glares at kshishkov [17:52:28] <ods15> eh, cmon, i've seen worse... maybe i'm blind to it as i know nut very well, but i think it wasn't that bad... [17:52:43] <mru> the spec is incomprehensible [17:53:18] <mru> I've tried several times to read it but had to give up [17:53:38] <av500> the nut spec? [17:53:47] <mru> it's random blathering mixed with pseudocode of undocumented syntax [17:53:49] <JEEBsv> it makes you go nuts [17:53:52] * JEEBsv ducks [17:54:34] <iive> av500: I think you can only make him finish it, if you threaten him with extradition (for real). [17:54:59] <av500> iive: extradiction *to* Real will help even more [17:55:17] * ods15 looks up extradiction [17:55:36] <av500> ods15: a free plane flight with a bag over your head [17:55:42] <ods15> yeah, got it [17:56:24] <gnafu> Actually, "extradiction" might be something like super enunciation. "Extradition," on the other hand, would be what av500 said. [17:56:28] * gnafu ducks. [17:56:48] <iive> av500: no, that's rendition. extradition is without bag. [17:58:28] <av500> iive: so one can watch the movie? [17:59:14] <iive> av500: sure if the tv and headphones work. [18:07:47] <ods15> ok i don't understand match_time_delta ... [18:09:04] <ods15> i can only guess that it is related to streaming, because i remember michaelni wanted some timestamp thing for streaming (iirc it was about setop boxes clocks staying synced to encoder clock), but i don't see how it is realted or what this match_time_delta is supposed to do... [18:09:57] <av500> PCR [18:10:03] <av500> like PCR in TS [18:10:43] <av500> ah no [18:15:47] * elenril couldn't understand how index in nut works last time he looked at it [18:23:50] <ods15> elenril, yeah, i JUST looked at that code.. and, well, i admit it's a bit of a over-complicated compression algo, but it is not a big deal... [18:24:43] <ods15> took me about a minute, but i managed to figure out again what it means... [18:25:12] <elenril> maybe because you wrote it =p [18:25:15] <ods15> i admit, that's not a fair test, since i wrote (parts of) it, but it was quite a few years ago it [18:25:29] <ods15> caught me in mid type :) [18:25:52] <elenril> you can expect any kind of intelligence from people writing demuxers [18:25:56] <elenril> *can't [18:26:44] <ods15> i don't really expect anything at all :) i'm not really interested in this anymore [18:27:08] <ods15> i am actually interested, from a pedagogial point of view, how it could be written better... [18:28:11] <ods15> i think it should have a comment right before it: "WARNING: the following pseudo code is an obfucated semi-compression algo..." [18:29:34] <ods15> besides that, not sure what more should be done... it's already pretty much the C code that it ought to be anyway (the code in libnut/demuxer.c is the same almost line-for-line), so understanding it is not really a prequisite for implementing it... [18:34:41] <elenril> BBB: i don't think making a macro for seek(SEEK_CUR) is a good idea [18:47:26] <BBB> elenril: uhm... ok, I guess, just changing all functions is fine also [19:12:48] <BBB> kshishkov: I guess the frame or MB layer in vc1 has no way to specify what the last mbrow is for a slice? the only thing I can think of right now is tot est that we're atthe end of the input buffer after each mbrow [20:15:54] <mru> hmm, which compiler shall we torment today? [20:18:09] <andoma> http://en.wikipedia.org/wiki/Lattice_C [20:22:59] <saintdev> Turbo C [20:23:41] <mru> real ones please [20:24:24] <Dark_Shikari> Borland [20:24:33] <saintdev> Dark_Shikari: that's Turbo C [20:24:41] <Dark_Shikari> Oh, yeah. [20:24:45] <Dark_Shikari> QBASIC [20:24:47] * Dark_Shikari runs [20:25:41] <elenril> msvc? [20:26:14] <mru> I said real [20:26:30] <saintdev> i think you need to better define real [20:28:48] <mru> something people use and has a fighting chance of building ffmpeg [20:29:18] <elenril> BBB: what's up with -mt? [20:29:35] <saintdev> according to wikipedia, lots of people use Turbo C [20:29:50] <saintdev> "It has since been widely adopted for educational use, especially in India" [20:29:50] <JEEBsv> lol [20:29:53] <JEEBsv> ah yeah [20:29:59] <JEEBsv> Yeah, I know Indians who use it :/ [20:30:06] <saintdev> JEEBsv: lol [20:30:54] <JEEBsv> But it's really easy to get them to other compilers when their lecturer or whatever doesn't expect only Turbo C [20:41:33] <BBB> astrange: what's up with ffmpeg-mt? [20:41:40] <BBB> elenril: waiting for astrange to fix his patch after I told him how to :-p [20:41:55] <elenril> why don't you fix it yourself =p [21:04:58] <astrange> i'll do it now [21:05:54] <astrange> can you apply patches when i just reply to the thread about them? typing out the send-email command takes a while [21:08:55] <spaam> mru: pcc? [21:09:18] <BBB> astrange: yes [21:09:23] <BBB> astrange: and thank :) [21:09:25] <BBB> +s [21:11:31] <mru> spaam: already tried [21:11:32] <mru> it failed [21:12:00] <mru> too many ICEs in critical places for workarounds too [21:14:26] <spaam> mru: watcom ? [21:14:37] <spaam> http://en.wikipedia.org/wiki/Watcom_C_compiler [21:14:57] <saintdev> djgpp [21:15:09] <mru> djgpp is gcc [21:15:20] <saintdev> oh, didn't know that [21:15:21] <mru> and isn't that what's behind fate/dos? [21:15:41] <lu_zero> mru: did you report pcc people the issues? [21:15:43] <lu_zero> btw [21:15:47] <lu_zero> tcc ? [21:15:52] <wbs> mru: yes, djgpp is behind fate/dos [21:16:09] <spaam> mru: int? [21:16:11] <spaam> cint [21:16:57] <spaam> it was a interpreter . [21:17:21] <Flameeyes> fate/dos? [21:17:28] <spaam> tcc? [21:17:56] <saintdev> Flameeyes: my thoughts exactly [21:18:11] <Flameeyes> saintdev: my thoughts are "dos fate is to die"... [21:18:21] <Flameeyes> dos's [21:18:22] <Flameeyes> dos' [21:18:23] <saintdev> lol [21:18:24] <Flameeyes> whatever.. [21:18:48] * Flameeyes waits for lu_zero to hit him with a branch... [21:18:48] <wbs> I do think it's quite dead already... michael kostylev seems to be running the tests with dosemu [21:18:58] <Flameeyes> not for the pun though [21:19:06] <Flameeyes> wbs: not even qemu/freedos? [21:19:30] <wbs> but I guess it's useful for routinely testing stuff in weird header environments at least [21:20:08] <wbs> Flameeyes: no, it seems to be dosemu (which runs the code without emulation iirc), but it uses quite a few components from freedos [21:20:30] <wbs> that is, it's kinda virtualized [21:20:44] <wbs> but qemu can do that too, right? [21:21:18] <Flameeyes> dosemu last I knew wasn't really an emulator as much as an implementation of the BIOS/DOS interrupts [21:22:01] <wbs> yeah [21:22:29] <wbs> it at least probably has the lowest overhead and simplest integration for actually running all the tests, without having to do the building within that environment [21:24:17] <iive> dosemu is virtualizator. [21:30:54] <BBB> \o/ vc1 slices are mostly working [21:31:27] <JEEBsv> congrats [21:37:37] <gnafu> BBB: Who cares about VC1? Why aren't you workin on xvp8? [21:37:39] * gnafu ducks. [21:37:54] <JEEBsv> :D [21:42:27] <kurosu> are there still any new bluray being produced with vc1 encoded video ? [21:42:44] <astrange> we have to support old ones too [21:43:23] <gnafu> kurosu: For the sake of the children, I hope not. [21:45:40] <kurosu> and what about vp8 and kittens ? [21:47:14] <gnafu> kurosu: Isn't that redundant? I always thought VP8 /was/ kittens./ [21:49:41] <gnafu> "Every time you code for VC1 support, God kills a kitten." [22:38:34] <Sean_McG> that meme is so tired. [22:40:16] <mru> every time you use a meme, god kills a kitten [22:40:24] <Sean_McG> indeed [22:40:30] <Sean_McG> and hiya mru [22:49:10] <lu_zero> mru: and every time you use a god kitten kills a meme? [22:50:10] * mru does not use gods [22:52:11] <BBB> slices in b/p frames work [22:52:14] <BBB> slices in i frames break [22:52:15] <BBB> grmbl [22:52:20] * BBB summons kshishkov [22:54:00] <kurosu> yo dawg, i put more meme in your meme so that you can meme while you meme [22:54:40] <BBB> kurosu: do you know anything about vc1 slices? [23:00:30] <kurosu> BBB: no, i just now a bit about regular slices as found in other standards [23:00:40] <kurosu> *know [23:04:22] <mmu_man> eh [Announce] Now Accepting Applications for Mentoring Organizations for GSoC 2011 [23:04:51] <Kovensky> http://www.99chan.in/b/src/129876700594.jpg :awesome: [23:05:29] <BBB_> mmu_man: already done [23:06:50] <lu_zero_> uhmm