[FFmpeg-devel-irc] IRC log for 2010-04-29

[irc at mansr.com]

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