[FFmpeg-devel-irc] IRC log for 2011-02-28

[irc at mansr.com]

[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 at 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 at 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