[FFmpeg-devel-irc] IRC log for 2010-05-02

irc at mansr.com irc at mansr.com
Mon May 3 02:00:51 CEST 2010


[00:15:25] <Kovensky> _av500_: lol
[00:15:39] <Kovensky> (and sure is late lol)
[00:16:37] <mru> trololol
[03:54:12] <Kovensky> why do sun people top-post :(
[03:54:38] <Dark_Shikari> why does the pope shit in the woods?
[03:54:43] <Kovensky> lol
[03:54:50] <Kovensky> MAKES SENSE
[03:55:21] * Kovensky forgot that not everyone is sane in the internet and uses inline-post
[03:56:57] <ohsix> they miss the point of discussion and treat email like instant messenger :]
[03:58:21] <Kovensky> heh
[03:59:00] <Kovensky> another frequent thing: not snipping out the parts of the message you're not commenting on
[03:59:24] <Kovensky> like top-posting and including the entire contents of the previous message quoted D:
[04:02:33] <ohsix> some business types do that to keep a running log of whats been in a token ring type email discussion too; no archives or whatever for context
[04:06:26] <Kovensky> http://arc.opensolaris.org/caselog/PSARC/2009/571/mail <-- you can see a lot of top-posting here :(
[04:06:30] <Kovensky> and a few inline posters
[04:07:01] <Kovensky> and I just saw an inline poster that didn't crop off the parts of the message it didn't comment on ;v
[04:07:24] <Kovensky> meh, I'll just sleep
[04:08:47] <ohsix> there a special type of top poster that doesn't even read what he's commenting on, too :]
[06:22:03] <_av500_> gee, forget theora, mjpeg is the one to use: http://www.osnews.com/story/23236/Why_Our_Civilization_s_Video_Art_and_Culture_is_Threatened_by_the_MPEG-LA
[06:22:45] <Dark_Shikari> lol
[06:22:50] * _av500_ waits for libaa being advocated for free video
[06:23:15] <ohsix> ttyrec 4 lif
[06:31:10] * saintd3v patents libaa
[06:31:12] <saintd3v> muhahaha
[06:35:54] <saintd3v> good thing the uspto doesn't seem to care about prior art for software patents, hehe
[07:05:13] <pJok> _av500_, libcaca... you need color once in a while ;)
[07:27:08] <_av500_> pJok: no can do, i bet ansi codes are patented too...
[07:29:27] <pJok> but that is what my terminal on my phone runs...
[07:29:52] <_av500_> your freephone?
[07:30:00] <pJok> no
[07:30:03] <pJok> its covered in patents
[07:30:19] <pJok> it even plays h264
[07:30:23] <pJok> err
[07:30:24] <pJok> no
[07:30:27] <pJok> mpeg4 only
[07:30:29] <_av500_> see
[07:30:41] <pJok> and of course 3gpp
[07:31:09] <_av500_> we need video on freephones, made from sticks and strings only
[07:31:29] <pJok> but strings and sticks are probably also patented
[07:33:17] <saintd3v> _av500_: don't let apple know you're using sticks and strings, they'll come after you with lawyers
[07:35:39] <_av500_> i
[07:35:45] <_av500_> iGiveUp
[07:36:16] <saintd3v> sorry, that is trademarked
[07:36:16] * pJok has patented _av500_ 
[07:36:47] <ohsix> still, its a civil action to defend it
[07:36:52] <ohsix> fight!
[07:37:04] <saintd3v> ohsix: mortal kombat?
[07:37:37] <ohsix> depends on the judge
[07:37:59] <ohsix> it gets pretty wild in that patent troll jurisdiction in texas
[07:38:36] <_av500_> tell me about it...
[07:38:44] <pJok> i think all patents filed after something already was in use by others should be invalidated
[07:39:12] <ohsix> thats the vaunted ideal
[07:40:01] <ohsix> but the people accepting them don't have the capacity to do more than trivial rejection & prior art
[07:40:24] <ohsix> the inventors prior art is sometimes all they look at if its in the filings
[07:41:49] <ohsix> incumbent ip interests can flood them with applications for very small novelties and a certain percentage will make it no matter what; then they get down finding a way to extort people with them
[07:41:53] <_av500_> we once fought a patent on a "box that has 2 connectors and converts signals between them"
[07:42:33] <saintd3v> lol
[07:42:33] <ohsix> did you lose? man theres only so many ways you can have a box yo
[07:43:01] <_av500_> luckily our box had one connector on an attached cable..
[07:43:13] <ohsix> it would be cool if the process was merit based, but the applications are mostly treated in isolation
[07:55:09] <pJok> _av500_, that is when you put a second connector on it
[07:55:21] <pJok> gotta love patent trolls
[08:06:54] * _av500_ patents love trolls
[11:46:41] <mru> Dark_Shikari: what bs is this? http://news.ycombinator.com/item?id=1312344
[13:05:46] <_av500_> mru: its bs
[13:06:23] <_av500_> afaik, anybody can get that by sending an email to mpegla
[13:06:24] <mru> I thought the licence terms for h264 had been public all the time
[13:09:24] <_av500_> i think ppl thought the terms were patented too and never bothered to have a look
[13:10:01] <mru> if you're afraid what you see will contradict your position, better not look
[13:10:42] <_av500_> if you're afraid what you see will contradict your position, burn it at a stake
[13:10:49] <_av500_> on a stake?
[13:11:13] <janneg> the can't be that secret if mpeg-la sends them to people without prior contact
[13:11:44] <mru> steak...
[13:11:54] <_av500_> right
[13:12:20] <_av500_> janneg: i bet they send it to everybody that ask and has a non-aol email address
[13:12:23] <mru> can I have my licence medium rare, please
[13:13:15] <janneg> _av500_: or hotmal. afaik diego got them after asking per mail
[13:14:02] <pross-au> discussions over patents and licensing should be banned. they just destroy productivity.
[13:14:13] <_av500_> janneg: psst, dont tell
[13:14:25] <_av500_> pross-au: no, they are cheap entertainment
[13:14:36] <kshishkov> pross-au: agreed
[13:16:13] <pross-au> better to put your energy into building a better codec
[13:16:29] <pross-au> if there was a better codec then h264 available, we wouldnt be having this dicussion.
[13:19:21] <_av500_> there will be h265, the race between mpeg and xiph to create it is on..
[13:32:51] <Kovensky> "If this license was a computer program I'd have to class it as spaghetti code." <-- *this* license? what other non-WTFPL or non-BSD license can you classify as non-spaghetti
[13:33:33] <mru> none
[15:20:04] <_av500_> ah, fsf is aiming at the consumer vs commercial thing
[16:08:20] <CIA-7> ffmpeg: reimar * r23009 /trunk/libavcodec/avcodec.h:
[16:08:20] <CIA-7> ffmpeg: Clarify how allocation works for the picture argument for
[16:08:20] <CIA-7> ffmpeg: avcodec_decode_video3.
[16:17:03] <tetsuo55> hello
[16:19:48] <tetsuo55> KindDragon helped make a patch for a problem i have with the debug build of mpc-hc
[16:19:49] <tetsuo55> https://sourceforge.net/apps/trac/mpc-hc/changeset/1830
[16:20:09] <tetsuo55> i'm not exactly sure how it works or what it fixes but all problems disapear with it
[16:20:55] <tetsuo55> does the patc make any sense to you guys?
[16:21:48] <mru> no
[16:23:17] <mru> that condition can never occur
[16:23:58] <mru> the for loop runs twice, each time nb_codes iterations
[16:24:47] <mru> in each iteration, j is incremented only if the condition is true
[16:24:55] <iive> tetsuo55: what compiler are you using, what arch (32/64) and have you tried to make that condition into assertion, aka break into debugger.
[16:25:15] <mru> the two instances of the loop have complementary conditions, so j can never reach nb_codes
[16:25:56] <tetsuo55> ok i found out some more, this patch makes ffmpeg compilable with msvc (there are some other patches too that where already applied before)
[16:26:12] <mru> that patch does neither this nor that towards building with msvc
[16:26:22] <KindDragon> crash occur with only several files http://rd.yahoo.co.jp/tokushu/5cm/teaser01/?http://i.yimg.jp/images/evt/5cm/teaser8000k1280_720.wmv
[16:26:37] <tetsuo55> without the patch msvc throws a runtime error during compile
[16:26:51] <mru> well, msvc is known not to be a compiler
[16:26:52] <tetsuo55> or playback
[16:26:53] <tetsuo55> lol
[16:27:18] <tetsuo55> KindDragon please explain in a little more detail
[16:27:37] <KindDragon> Run-Time Check Failure #4 Stack area around _alloca memory reserved by function is corrupted
[16:28:08] <Yuvi> llvm writes beyond the vla too, but it didn't seem possible from the code
[16:28:30] <KindDragon> Sometimes j become equal nb_codes in  COPY(buf[j].bits && buf[j].bits <= nb_bits)
[16:29:08] <mru> gaaaah, how did that vla get there!?!?!??
[16:29:19] <mru> haven't I told you they're evil?
[16:30:03] <iive> there is something i don't get, the COPY macro is called twice, but j is zeroed only once
[16:31:12] * Kovensky pats mru
[16:31:29] <mru> Kovensky: if you want to please me, get rid of that vla
[16:32:17] <tetsuo55> so there is a real bug of sorts there?
[16:32:24] <mru> in the compiler, yes
[16:32:39] <mru> VLAs are unfortunately part of the C standard
[16:32:45] <tetsuo55> ok
[16:32:52] <mru> no, that's not ok at all
[16:33:17] <tetsuo55> ofcourse, just ok to your response
[16:36:23] <iive> mru: in that code, i see that j is zeroed, then COPY is called once, at exit j==nb_codes,  then there is qsort, and then copy is used again, without j been zeroed. is this how it should be done?
[16:36:49] <mru> the loop counts until _i_ reaches nb_codes
[16:37:17] <mru> j is only incremented when the condition in the macro invocation is true
[16:37:37] <mru> the two calls have almost complementary conditions
[16:37:54] <iive> j is always incremented in the loop.
[16:37:54] <mru> so it will be true less than nb_codes times
[16:38:02] <mru> iive: is not
[16:38:04] <iive> maybe i have old copy. let me svn up.
[16:38:08] <mru> there's a continue there
[16:38:22] <mru> line 304 in svn
[16:39:18] * Kovensky wishes mailman included a link to the public archived version of each mail in the ML signature
[16:39:22] <iive> i missed that.
[16:39:44] <mru> hmm wait, maybe I'm stupid too
[16:41:22] <mru> no, I'm not
[16:43:31] <Yuvi> looks like it writes over the end of the vla in gcc too
[16:43:42] <mru> Yuvi: how is that possible?
[16:45:22] <Yuvi> dunno, but http://pastie.org/942540 doesn't print the expected values
[16:52:46] <Yuvi> the GET_DATA() before the condition check?
[16:52:59] <mru> what of it?
[16:53:19] <Yuvi> can't that run after j == nb_codes from a previous iteration
[16:53:20] <Yuvi> ?
[16:54:18] <mru> hmm, if all the values pass the first condition, yes
[16:54:34] <KindDragon> yes, rewriting stack in     for (i = 0; i < nb_codes; i++) {\
[16:54:36] <KindDragon>         GET_DATA(buf[j].bits, bits, i, bits_wrap, bits_size);\
[16:54:40] <KindDragon> in GET_DATA
[19:00:13] <CIA-7> ffmpeg: cehoyos * r23010 /trunk/configure: Allow to set archiver tool ar.
[21:40:46] <mru> siretart: ping
[21:53:16] <CIA-7> ffmpeg: rbultje * r23011 /trunk/libavcodec/wmavoice.c: Another buffer overflow, fixes issue1758.


More information about the FFmpeg-devel-irc mailing list