[FFmpeg-devel-irc] IRC log for 2010-09-20

[irc at mansr.com]

[02:02:34] <saintdev> i wonder if gabriel is ever going to get back to me :(
[05:24:33] <peloverde> greetings gentlemen
[05:24:39] <thresh> moroning
[06:29:30] <KotH> salut mes amis
[06:36:08] <Tjoppen> morning
[06:39:31] <CIA-63> ffmpeg: mstorsjo * r25147 /trunk/libavformat/udp.c:
[06:39:32] <CIA-63> ffmpeg: Check for the IPPROTO_IPV6 define before using it
[06:39:32] <CIA-63> ffmpeg: This fixes building on FreeBSD in some configurations, if the IPv6 multicast
[06:39:32] <CIA-63> ffmpeg: structs are available, but IPPROTO_IPV6 isn't defined.
[07:02:50] <_av500_> gm
[07:03:02] <mru> morning
[07:05:45] <cartman> mrnng
[07:10:26] <KotH> günaydin cartman, av500
[07:10:29] <KotH> hoi mru
[07:11:15] <cartman> KotH: av500 knows Turkish since when? ;)
[07:11:29] <KotH> cartman: he lives in east turkey :)
[07:11:42] <cartman> oooh
[07:12:22] <KotH> gtg.. bye boys
[07:13:07] <kshishkov> _av500_: Darmstadt may be not the best place around here, but it's lovely
[07:14:21] <_av500_> gee
[07:14:35] <_av500_> where gave you been :)
[07:16:29] <kshishkov> just walked in the direction Hbf - Univ.Library (aka Schloss) - somewhere yonder
[07:16:44] <kshishkov> BTW, some of your trams are outdated, the reek of steam
[07:17:45] <_av500_> kshishkov: yeah, it was steam train days
[07:18:23] <kshishkov> _av500_: also good shop at Hbf building, it has almost sane working hours
[07:19:32] <_av500_> its the only one :)
[07:20:01] <kshishkov> yes, and it has suspiciously long queues. I thought Germans don't like shopping on Sundays
[07:21:04] <_av500_> germans dont like anything
[07:21:41] <kshishkov> even beer?
[07:22:12] <_av500_> there is always an exception
[07:23:45] <kshishkov> _av500_: personally I'd pick Darmstadt for living over Berlin or Frankfurt. But not Sundsvall or Stockholm.
[07:24:10] <mru> you're too picky
[07:24:26] <mru> oslo was ok
[07:24:27] <kshishkov> indeed I am
[07:24:30] <mru> a bit too expensive
[07:24:58] * thresh has been on dacha eating shashlyk all the weekend.
[07:25:22] <_av500_> thresh: so a good morning today?
[07:25:26] <kshishkov> thresh: ну ты его пожарил бы сначала что ли
[07:25:40] <thresh> av500: not quite, I didnt get enough sleep
[07:26:27] <_av500_> you ruskies complain even more then ze germans
[07:26:39] <kshishkov> mru: Oslo left an impression of lacking taste completely. And wobbly pavement. And garbage on Jernvegtorget.
[07:26:41] <lu_zero> good morning
[07:27:14] <kshishkov> lu_zero: it "buon giorno" or "yawn" in Italian?
[07:27:22] <thresh> OTOH, i'll probably move to a new flat in Nov
[07:27:26] <thresh> so that kinda makes me happy
[07:27:48] <kshishkov> thresh: where to?
[07:27:56] <lu_zero> kshishkov: "buon giorno"
[07:28:02] <thresh> kshishkov: still here, Moscow Area
[07:28:17] <lu_zero> the tired alternative is " 'ngiorno"
[07:28:54] <kshishkov> lu_zero: noted, thanks
[07:29:59] <kshishkov> thresh: http://divov.livejournal.com/268200.html , next to last sentence
[07:30:42] <thresh> kshishkov: yep, Moscow sucks for living
[07:31:06] <thresh> that's why I'm just outside, so ~20 EUR for taxi and you're in Moscow
[07:32:53] <thresh> 2 EUR if you can travel with filthy co-citizens
[07:35:38] <cartman> thresh: I do that everyday
[07:35:41] <cartman> feels refreshing
[07:36:40] <thresh> you mean travel with low-class citizens?
[07:38:42] <cartman> there is no low-class citizens, there are just people who I politically disagree :p
[07:43:01] <lu_zero> uhm how to make ffmpeg not try to read from stdin?
[07:43:09] <Dark_Shikari> don't use -i -?
[07:43:38] <kshishkov> lu_zero: ffmpeg -i infile < /dev/null
[07:45:03] <lu_zero> I'm trying to see if the pipe protocol works for fd with a different number both for send and receive
[07:49:56] <j0sh> i thought pipes worked from stdin only?
[07:50:02] <j0sh> unless you explicitly pass a named pipe
[07:50:16] <lu_zero> nope
[07:50:31] <mru> on linux you can say /dev/fd/X
[07:50:33] <lu_zero> pipe is supposed to work passing the fd number
[07:50:34] <mru> for any X
[07:50:48] <lu_zero> e.g pipe:5
[07:51:02] <mru> and that
[07:51:08] <j0sh> fd == any fd? even, say, sockets?
[07:51:23] <mru> read and write work any fd
[07:51:27] <mru> that's the beauty
[07:51:31] <j0sh> cool
[07:51:34] <Dark_Shikari> "everything's a file"
[07:51:44] <mru> except sysv ipc
[07:52:45] * Dark_Shikari loves how firefox takes 5 minutes to close because of de-swapping itself
[07:53:01] * mru doesn't use swap
[07:53:07] * j0sh uses chrome
[07:53:29] <mru> I'd try it if it didn't depend on dbus and gconf
[07:53:32] <Dark_Shikari> mru: even if there was no swap it would still take ages, half of the time it's actually cpu-bound
[07:53:39] <mru> wow
[07:53:44] <Dark_Shikari> yes, cpu-bound on SHUTDOWN
[07:53:47] <microchip_> closes really fast here
[07:53:55] <Dark_Shikari> microchip_: has it been open with 100 tabs for 3 days?
[07:53:57] <mru> kill -9
[07:54:03] <microchip_> nope
[07:54:08] <Dark_Shikari> mru: then it loses its cache, and it has to redownload everything
[07:54:17] <Dark_Shikari> so it takes... a billion times longer to start up again.
[07:54:19] <microchip_> 100 tabs, lol
[07:54:30] <Dark_Shikari> The best part is how if you have firefox open for a few days with a lot of tabs
[07:54:33] <Dark_Shikari> then you close them all
[07:54:36] <Dark_Shikari> it still uses 1.5GB
[07:54:45] <Dark_Shikari> And it still takes 5 minutes to shut down
[07:54:48] <lu_zero> Dark_Shikari: which firefox are you using?
[07:54:51] <Dark_Shikari> latest
[07:54:55] <microchip_> doesn't clean up its mem?
[07:55:02] <Dark_Shikari> microchip_: leaaaaaaaaaaaak
[07:55:38] <ohsix> Dark_Shikari: bartab
[07:56:03] <lu_zero> 4beta5 was quite fine
[07:56:03] <Dark_Shikari> ohsix: that doesn't stop firefox from leaking
[07:56:12] * lu_zero is trying 4beta7 now
[07:56:14] <Dark_Shikari> bartab would help if the problem actually _was_ tabs eating memory
[07:56:21] <Dark_Shikari> but even if I *close* them all, it still doesn't save any memory
[07:56:27] <Dark_Shikari> I've actually seen memory usage go *up* after closing tabs.
[07:56:41] <ohsix> vm size changing isn't a leak
[07:57:00] <Dark_Shikari> 1.5 gigabytes of allocated memory with nothing open is a leak
[07:57:01] <Dark_Shikari> fullstop
[07:57:23] <ohsix> and it doesn't tell you what memory is actually being used in said vm space
[07:57:27] <Dark_Shikari> And you can't claim "oh, it's not being used", because if it wasn't being used, it wouldn't have to swap every last bit back in when shutting down firefox.
[07:58:05] <mru> strictly speaking it isn't a leak
[07:58:16] <ohsix> if its really discardable ff shouldn't touch it on shutdown, and maybe it does do too much of that
[07:58:17] <mru> precisely because it _is_ able to access it again
[07:58:45] <Dark_Shikari> mru: not really, since it keeps its own VM subsystem
[07:58:51] <mru> if it were truly leaked, there'd be no references left to it, and the shutdown wouldn't be able to bring it in
[07:58:55] <Dark_Shikari> if I make a program that keeps a list of all mallocs, but still doesn't try to free them
[07:58:58] <Dark_Shikari> it's still leaking
[07:59:04] <ohsix> before they switch to jemalloc the vm size was really fun with the default allocators :]
[07:59:05] <Dark_Shikari> just keeping a list doesn't make it not a leak
[07:59:09] <mru> bloat is the proper technical term for it
[07:59:28] <Dark_Shikari> mru: I would define a leak as an O(N) memory usage that is not reduced when reducing N.
[07:59:35] <Dark_Shikari> at least, the kind of leak that matters.
[07:59:55] <Dark_Shikari> for example, O(tabs opened).
[08:00:05] <mru> if as you suggest, they simply track mallocs and free them on exit, then it's a leak
[08:00:16] <Dark_Shikari> mru: well they have their own VM subsystem basically
[08:00:25] <lu_zero> uhm
[08:00:26] <Dark_Shikari> so even if firefox itself leaks like crazy, it'll still free on close
[08:00:36] <Dark_Shikari> since on close the whole system is destroyed
[08:00:38] <mru> which is utterly pointless
[08:00:47] <lu_zero> we lack a way to suppress streams in an effective way...
[08:00:52] <mru> when a process exits, all its resources are freed by the os
[08:00:54] <ohsix> VIRT is not an accurate assessment of anything; except if its growing fast its suspicious
[08:00:55] <lu_zero> and -map doesn't help at all
[08:01:19] <Dark_Shikari> ohsix: Sure it is
[08:01:23] <mru> virtual size could be all null cow pages
[08:01:27] <Dark_Shikari> it's an accurate assessment of when firefox will crash.
[08:01:29] <Dark_Shikari> Extremely accurate.
[08:01:34] <Dark_Shikari> When firefox hits 1.5GB VIRT, it crashes.
[08:01:36] <Dark_Shikari> (roughly)
[08:01:46] <Dark_Shikari> I have replicated this at least 50 times over 2+ years.
[08:01:54] <Dark_Shikari> It has never passed that mark without crashing.
[08:02:03] <Dark_Shikari> (NB: 32-bit OS)
[08:02:03] <mru> mine's at 950M now
[08:02:06] <Dark_Shikari> er, 32-bit firefox.
[08:02:09] <Dark_Shikari> 64-bit OS
[08:02:13] <ohsix> are you on an os with a 2g:2g address split for user/kernel?
[08:02:15] <Dark_Shikari> Yes
[08:02:20] <Dark_Shikari> That's why it crashes
[08:02:24] <Dark_Shikari> It runs out of address space
[08:02:29] <Dark_Shikari> Thus, VIRT does matter.
[08:02:35] <Dark_Shikari> Because VIRT is the amount of address space it's using.
[08:02:44] <kshishkov> maybe it's their subtle way of encouraging people using 64-bit?
[08:03:01] <ohsix> not as an indicator of a leak; also ff has a hard cap you have to willfully override for that aspect
[08:03:04] <Dark_Shikari> Not while their 64-bit builds are still slow as fuck
[08:03:12] <Dark_Shikari> ohsix: no, it doesn't have a cap.
[08:03:21] <Dark_Shikari> And yes, that is an indicator of a leak
[08:03:23] <Dark_Shikari> a leak of VM
[08:03:39] <kshishkov> you know, a lot of problems can be solved by simply adding a near-infinte amount of RAM (or so Java/Firefox/Windows devs think)
[08:03:41] <ohsix> how do you leak vm
[08:04:32] <Dark_Shikari> ohsix: ever-increasing allocation that never gets freed
[08:04:33] <ohsix> just the same, i'll dig up the memory limit thing in a bit here
[08:04:34] <Dark_Shikari> trivial.
[08:04:43] <Dark_Shikari> I have never modified any memory limit settings.
[08:04:48] <Dark_Shikari> The only memory limit is the point where it segfaults.
[08:04:54] <Dark_Shikari> Because it doesn't check its mallocs.
[08:04:57] <kshishkov> Dark_Shikari: 64-bit Firefox is faster and takes less RAMsince it doesn't have Flash plugin by default
[08:05:04] <Dark_Shikari> kshishkov: The JIT is still shit
[08:05:06] <Dark_Shikari> or nonexistent
[08:05:13] <ohsix> vm is taken in huge chunks by heaps that still might have >0 items in there; the heaps won't go away
[08:05:30] <Dark_Shikari> ohsix: Which means that their allocator is a pile of shit
[08:05:46] <ohsix> ehh, the 64bit jit stuff was pushed up to 6.4
[08:05:47] <Dark_Shikari> they should stop reimplementing the wheel badly
[08:06:24] <ohsix> they aren't; the heap stuff was old news years ago when they switched to jemalloc, stop moving the goalposts :P
[08:06:37] <Dark_Shikari> this doesn't make a difference though, it still crashes
[08:06:54] <ohsix> and they fixed it because the crt alllocator on windows was really bad for the working set
[08:06:59] <Dark_Shikari> Under a working heap system, the worst-case scenario would be that firefox always uses the peak memory usage.
[08:07:08] <Dark_Shikari> that is, suppose firefox uses 600MB at peak due to lots of tabs
[08:07:17] <Dark_Shikari> the worst case is it can never free any of the heap blocks because there's one object in each
[08:07:21] <Dark_Shikari> thus, memory usage stays at 600MB.
[08:07:44] <Dark_Shikari> however, because firefox is broken and shit, the results it gets are worse than this hypothetical worst-case.
[08:08:06] <Dark_Shikari> in short, firefox should have memory usage O(max tabs open at once)
[08:08:12] <elenril> why don't you switch to chromium then?
[08:08:12] <microchip_> how is IE doing with so many tabs?
[08:08:13] <mru> any form of garbage collection is a very selfish form of memory "management"
[08:08:22] <Dark_Shikari> but instead it has memory usage O(A*max tabs open at once + B*total tabs opened ever)
[08:08:28] <ohsix> heap usage will go down; in vm they can be discontiguous and moved around, the decoupling of the two is important
[08:08:29] <Dark_Shikari> elenril: no tree style tabs
[08:08:31] <Dark_Shikari> interface is shit
[08:08:43] <mru> "if I can't use this memory, then neither shall anybody else"
[08:09:06] <Dark_Shikari> mru: if "garbage collection" worked, it would rm /usr/bin/firefox
[08:09:16] <kshishkov> mru: in Russian it's called "dog on hay"
[08:10:12] <ohsix> if you rm firefox while its running, garbage collection will work when the in core inode is closed :D
[08:11:07] <kshishkov> ohsix: yes, that's an old trick for creating really temporary files
[08:12:00] <microchip_> Dark_Shikari: have you used IE with so many tabs?
[08:12:10] <ohsix> dunno if its a trick if it was planned to work like that, and linux can open stuff in /proc/pid/fd and keep them around
[08:12:22] <lu_zero> Dark_Shikari: beta7 seems not to keep having memory growing per tab
[08:12:52] <kshishkov> ohsix: yes, it was - IIRC I read about it in some very old book on C programming
[08:13:21] <Dark_Shikari> microchip_: it's probably terrible
[08:13:32] <Dark_Shikari> chrome works quite well but the interface just doesn't work
[08:13:42] <ohsix> i guess; but you could also read how the os handles files, and back then it was pretty comprehensible, shrug
[08:13:53] <kshishkov> lu_zero: did they plug a leak completely or just made it slower?
[08:14:35] <ohsix> Dark_Shikari: do you have browser.cache.memory.capacity anywhere in about:config
[08:14:40] <kshishkov> ohsix: yes, it's Unix trick. IIRC same story with creating empty file - create, seek, close
[08:15:23] <ohsix> the real trick to that is if the fs supports extents and sparse files it'll be instant :P
[08:15:37] <Dark_Shikari> ohsix: nope
[08:15:56] <lu_zero> kshishkov: given memory usage goes down I think they plugged it
[08:16:20] <Dark_Shikari> haven't they claimed to have plugged it every one of the last 15 versions?
[08:16:33] <ohsix> k, are you using anyt extensions that are more than just xul/xbl bindings? like ones with 3rd party xpcom objects or .dll's
[08:16:37] <lu_zero> Dark_Shikari: they did for me since 3.6
[08:16:51] <Dark_Shikari> have they fixed the entire browser being singlethreaded?
[08:16:52] <lu_zero> at least my usage pattern
[08:17:08] <Dark_Shikari> ohsix: the only particularly intensive extension I have is probably adblock
[08:17:15] <lu_zero> Dark_Shikari: plugins live in different processes at least
[08:17:21] <ohsix> Dark_Shikari: the kind of minification you're asking for is just migrating heaps and giving the vm space back
[08:17:31] * lu_zero is puzzled
[08:17:40] <Dark_Shikari> lu_zero: yeah but that doesn't help when firefox is slower than flash
[08:17:42] <Dark_Shikari> i.e. all the time
[08:18:07] <lu_zero> Dark_Shikari: flash (and java) are the only crashing parts in firefox
[08:18:15] <lu_zero> at least for my usage
[08:18:19] <Dark_Shikari> firefox is a pretty crashy part of firefox
[08:18:25] <lu_zero> not for me
[08:18:32] <ohsix> Dark_Shikari: we'll get on top of this this time around, brb
[08:18:48] <lu_zero> the only time it was crashing was for flash and java
[08:19:01] <Dark_Shikari> "the only time it crashed was when I was using it"
[08:19:10] <kshishkov> Dark_Shikari: elinks - >60 tabs open, 84MB VM, builting adblock. Not closing it for a week
[08:19:13] <lu_zero> now I get the sad lego brick from time to time
[08:19:28] <Dark_Shikari> kshishkov: it's easy to fit in 84MB if you don't have to display images
[08:20:02] <kshishkov> Dark_Shikari: I find that images are not needed in many cases
[08:20:23] <Dark_Shikari> 90% of the worthwhile content on the internet is lolcats
[08:20:24] <elenril> inb4 4chan
[08:21:00] <funman> http://i.imgur.com/du8LI.jpg
[08:21:04] <kshishkov> Dark_Shikari: it's tvtropes for elenril
[08:21:40] <ohsix> the way ff picks its memory cache size is probably a bit optimistic; barring other stuff playing around in its address space anyways (and theres a lot of crap that does on windows, like mouse software
[08:21:57] * elenril wonders why does flash seem faster inside xephyr
[08:22:04] <Dark_Shikari> "just allocate all you want" is an optimistic strategy, yes
[08:22:39] <ohsix> its not that, either; and like i said its just vm space in the end, they're long lived objects and sometimes they're ejected; that's what the os is supposed to do
[08:23:05] <kshishkov> Dark_Shikari: allocate all you want with 150% ratio just in case
[08:23:10] <ohsix> but i'm still perplexed by the fact that firefox crashes before the os totally wedges itself; i've had ff crash on windows a lot, but not without really weird circumstances
[08:23:36] <Dark_Shikari> ohsix: the OS is 64-bit
[08:23:41] <Dark_Shikari> it won't wedge itself when an app allocates 2GB
[08:23:57] <ohsix> ff does have a "leak" of sorts on windows too, but not because its leaking objects but with gdi its an untracked "heap" of finite size and they don't measure how many objects they use
[08:24:14] <ohsix> right, but memory is hardly as inexaustable as other things ff uses
[08:24:23] <Dark_Shikari> yada yada gdi objects yada yada
[08:24:46] <ohsix> :] i've got bug numbers at least!
[08:26:27] <ohsix> think about how bad it would be if file handles had the same visibility of gdi objects; generally you can assume you can open 32 files no problem, maybe up to 1024; but people know those numbers and they can set the policy for them with one composite number; and when you exceed the limit it doesn't totally thrash the ui of the os, or break file i/o in already open files
[08:27:55] <ohsix> anyways, gonna find the name of the rdf i need to look at and how to get a list of dlls in a process with stuff that already comes with windows, should give up some info, if its firefox and some other junk running in its address space you can probably "fix" it by sidestepping the problem and shrinking the memory cache instead of letting it do its heuristics
[08:28:27] <Dark_Shikari> but what happens when it runs out of memory?
[08:28:29] <Dark_Shikari> it'll just crash
[08:28:36] <Dark_Shikari> even if it doesn't hit the address space limit
[08:28:40] <Dark_Shikari> it's practically the same thing
[08:28:43] <Dark_Shikari> it means a malloc will fail
[08:29:06] <ohsix> have you let it generate a minidump?
[08:29:13] <ohsix> what module is it faulting in
[08:29:18] <Dark_Shikari> dump?  what?  it just sends me to the windows crash screen
[08:29:30] <ohsix> try "view contents of report"
[08:29:46] <Dark_Shikari> meh, next time.
[08:29:51] <ohsix> but a dumpfile is also generated somewhere in system32
[08:29:52] <Dark_Shikari> it'll be another few days before it hits enough memory
[08:30:01] <ohsix> word
[08:30:17] <ohsix> brb i'll get that info in a few
[08:35:44] <ohsix> Dark_Shikari: the extensions.ini/rdf file from the profile dir you're using and the output of tasklist /fi "imagename eq firefox.exe" /m
[08:36:44] <Dark_Shikari> firefox.exe                   4488 ntdll.dll, wow64.dll, wow64win.dll, wow64cpu.dll
[08:37:37] <ohsix> to a pastebin that is
[08:37:42] <Dark_Shikari> That's it.
[08:37:43] <Dark_Shikari> It's one line.
[08:37:45] <Dark_Shikari> Why pastebin it?
[08:38:14] <ohsix> extensions.rdf/ini should be a k or two
[08:38:28] <Dark_Shikari> well yes, but I meant the other one
[08:38:34] <ohsix> k
[08:38:47] <Dark_Shikari> http://www.mediafire.com/?zwpv71eaptiadkl
[08:38:58] <ohsix> its weird that xul.dll isn't even in there; not sure how tasklist deals with wow64, it might need voodoo
[08:40:30] <ohsix> i know process explorer will list the modules, if you already have it handy
[08:40:57] <Dark_Shikari> any magic from extensions.rdf?
[08:41:48] <ohsix> ya it'll take a bit to filter out the junk though, wanna take it to pm?
[08:41:55] <mru> #define __yyrhdgdtfs66ytgetrfd unsigned long long
[08:41:57] <Dark_Shikari> don't really care
[08:42:07] <ohsix> thought someone else might
[08:42:09] <Dark_Shikari> mru: #define long long long
[08:42:09] * mru blames funman for ^
[08:42:46] <funman> i have to add a "© Ac1dB1tch3z"
[09:23:25] <funman> mru: i dont see a VERSION in lame.h
[09:24:10] <mru> me neither
[09:24:29] <funman> hip_decode_init() is still present in the header btw
[09:24:47] <mru> yes, I know
[09:24:51] <funman> you could try to redefine it and see if it breaks?
[09:27:47] <funman> if that sounds ok i can make a patch
[09:28:07] <mru> let me think about it
[09:45:05] <funman> where can i checkout svn for ffmpeg.org website?
[09:45:40] <mru> svn://svn.ffmpeg.org/ffmpeg.org/trunk
[10:31:19] <mru> no reply to the stack alignment question
[10:38:43] <mru> cartman: did you stop running your ubuntu/clang fate config?
[10:39:01] <cartman> mru: I thought it was reduntant
[10:39:11] <cartman> s/t/d
[10:39:21] <mru> yes, agree
[10:39:27] <cartman> okies
[11:35:18] <CIA-63> ffmpeg: banan * r25148 /trunk/libavcodec/imgconvert.c: Support deinterlacing of YUVJ420P.
[11:36:14] <merbzt> is there a way of getting rid of all the bytestream warnings ?
[11:36:25] <mru> example?
[11:36:41] <merbzt> libavcodec/bytestream.h:44: warning: ‘bytestream_get_le64’ defined but not used
[11:37:08] <mru> what configuration are you using?
[11:37:19] <mru> those are all inline
[11:37:23] <mru> shouldn't be warned about
[11:38:02] <merbzt> lucid stock conf
[11:38:13] <mru> doesn't mean a thing me
[11:38:20] <mru> and you didn't say what ffmpeg configuration
[11:38:25] <mru> any unusual options?
[11:38:33] <wbs> --disable-optimizations may give that
[11:38:35] <wbs> iirc
[11:38:36] <merbzt> er ok :)
[11:38:44] <merbzt> yeah those are a bit unusual
[11:39:09] <merbzt> disable optimizations
[11:40:41] <mru> then you get what you asked for
[11:40:51] <mru> why are you doing that anyway?
[11:40:56] <mru> did that boost troll get to you?
[11:48:54] <merbzt> mru: just hacking around abit
[11:52:23] * jannau has still a patch to define av_always_inline to av_unused to avoid the warnings for --enable-small || --disable=optimizations
[11:53:44] <mru> that's the wrong fix for small
[11:54:08] <mru> most of the always_inline functions really should always be inlined
[12:01:48] <jannau> I'm just describing current configure behaviour. micheal added that in r3101
[13:30:19] <mru> hmm, michael seems unusually ranty today
[13:47:20] <lu_zero> and on a subject in which there isn't much to beat
[13:47:34] <lu_zero> we aren't talking about gcc or glibc
[13:52:00] <kshishkov> quite flamy statement you've made here
[13:52:35] <mru> gdb is better at what it does than gcc is at what it does
[13:55:33] * kshishkov still thinks that GCC primary goal is to boldly spread FSF hype
[13:55:56] <mru> without a doubt
[14:31:53] <mru> BBB___: still no reply on icc
[14:43:36] <_av500_> mru: its a forum, replies come after days...
[14:44:18] <mru> well, not so much replies
[14:44:31] <mru> more like... I think I'm having this issue too
[14:44:46] <mru> I use -fsome-completely-other switch, and it not work as I want
[14:44:51] <mru> plz give me teh codez
[14:46:54] <kierank> also "mru plz can i have your email adress. I want to talk 2u about dis problem"
[14:48:25] <spaam> if you dont give the it to mru. then mru will be like this panda http://idiotube.com/2010/09/never-say-no-to-a-panda/ ? ;O
[15:09:16] * KotH hates customers who think using keil-C is supperior to using gcc, when every code was written for the gcc/gas toolchain and they dont have the time to properly port stuff
[15:10:08] <mru> if the code is written for gcc and known to work well with it, there's no reason to switch
[15:10:21] <jenk> switch to clang to piss of RMS
[15:11:19] <mru> and feed jobs' ego?
[15:11:49] <kshishkov> mru: do you think it will notice your feeding?
[15:11:58] <mru> no
[15:12:00] <mru> nor will rms
[15:13:33] <kshishkov> at least rotten fruit company doesn't make fuss over inside software, only on end result
[15:13:55] <jenk> what does $teve have to do with clang?
[15:14:06] <mru> apple wrote most of it
[15:14:29] <mru> and when apple decides to abandon it, it will die
[15:14:32] <mru> _when_
[15:14:35] <jenk> o
[15:14:47] <jenk> maybe llvm will support it
[15:14:47] <KotH> mru: $customer thinks that keil is better because you pay for it
[15:14:52] <kshishkov> mru: RMS abandoned Emacs and it got better
[15:15:04] <mru> KotH: I can sell them a copy of gcc
[15:15:17] <KotH> mru: that quite a bit of code miscompiles with keil is a different story... and we are not yet talking about the switch from at&t asm to keil asm
[15:15:30] <KotH> mru: PLEASE DO!
[15:15:35] <mru> what target?
[15:15:40] <KotH> arm7
[15:15:42] <mru> at&t?
[15:15:49] <KotH> at&t asm syntax
[15:15:57] <mru> at&t arm wtf?
[15:16:22] <KotH> isnt that was gas uses?
[15:16:27] <mru> gas uses gas syntax
[15:16:33] <KotH> hmm..
[15:16:44] <mru> what is commonly referred to as "at&t" is a specific syntax for x86 asm
[15:16:45] * KotH thought that gas syntax was derived from at&t asm
[15:16:54] <KotH> oh..kay.. didnt know
[15:17:03] * kshishkov wonders why gas uses AT&T syntax and C was developed in Bell Labs, them being the same company
[15:18:01] <KotH> kshishkov: uhmm.. because the fsf thought it would be wise to do everything the same way as the big unix tools did
[15:18:18] <KotH> ie, just reimplement their tools w/o much improvement
[15:19:44] * kshishkov thinks that Unix was big improvement
[15:26:39] <KotH> to what?
[15:26:43] <KotH> multics? ;)
[15:30:44] <mru> KotH: try getting your customer to use keil ds-5
[15:30:53] <mru> it's gcc with a price tag
[15:32:58] <mru> and traditional keil is just armcc in a different wrapping
[15:33:37] <mru> and keil itself is owned by arm
[15:41:55] <KotH> mru: is ds5 a current product or will it be replaced by the armcc based one?
[15:42:13] <KotH> but it really looks good :)
[15:42:15] <mru> it's a rather new product
[15:42:57] <KotH> cool!
[18:08:10] <twnqx> hm, what was the reason of ‘NULL’ undeclared (first use in this function) again...
[18:08:36] <funman> missing stdlib.h
[18:09:15] <spaam> :)
[18:09:54] <twnqx> uh. i thought that wasn't necessary...
[18:13:33] <funman> the definition must come from somewhere
[18:13:58] <spaam>  /* Get size_t, wchar_t and NULL from <stddef.h>.  */
[18:14:10] <mru> stddef.h is where the spec says it's defined
[18:14:39] <mru> stdlib.h also
[18:15:02] <mru> if you care about fractions of sections of build time, stddef.h is likely faster to parse
[18:15:40] <funman> if you want to use more power and destroy the planet, #define _GNU_SOURCE #include <stdlib.h>
[18:23:50] <lu_zero> ^^;
[18:25:05] <spaam> o,o
[18:42:26] <mru> http://news.ycombinator.com/item?id=1709564
[18:43:07] <mru> comment by one zentechen: Does it support .rmvb format?
[18:43:19] <mru> (about vlc on ipad)
[18:45:56] <_av500_> ocourse
[18:46:16] <cartman> RMS will soon chime in I bet
[18:46:59] <mru> he doesn't have a stake in vlc so his opinion doesn't count
[18:47:06] <cartman> he ownz GPL
[18:47:19] <lu_zero> that won't say anything
[18:47:29] <mru> he had a hand in writing the text of the gpl, yes
[18:47:30] <cartman> GPL is not compatible with AppStore
[18:47:39] <cartman> hence he can flame all day long
[18:47:51] <mru> that's his opinion
[18:47:54] <lu_zero> cartman: I don't see why
[18:47:57] <mru> and flame he will
[18:48:02] <cartman> lu_zero: I think due to signing
[18:48:03] <lu_zero> hi DonDiego
[18:48:08] <lu_zero> cartman: so?
[18:48:11] <mru> apple and the vlc devs seem not to mind
[18:48:20] <cartman> lu_zero: incompatible with some GPL section bla bla
[18:48:26] <mru> but it's not
[18:48:33] <mru> they do give you the source code
[18:48:52] <mru> the gpl doesn't require the source to be included in the binary distribution
[18:49:04] <mru> it doesn't even have to be available through the same channels
[18:49:15] <mru> all it requires is that the source is available _somehow_
[18:49:19] <mru> at no additional cost
[18:49:36] <cartman> I don't care, I hope GPL dies :P
[18:51:02] <lu_zero> I hope it doesn't
[18:51:11] <_av500_> now, if i take vlc from app store and start charging $10 for it, call it "superduperplayer"?
[18:51:11] <funman> <@mru> he doesn't have a stake in vlc
[18:51:14] <mru> s/gpl/rms/
[18:51:15] <funman> you wish!
[18:51:28] <mru> funman: I don't see any (c) rms in there
[18:51:37] <mru> I do see some (c) mru though
[18:51:37] <_av500_> and i advertise .rmvb....
[18:51:38] <funman> he bought us
[18:51:49] <funman> http://www.fsf.org/campaigns/playogg/
[18:52:04] <cartman> GPL shall die, LGPL shall prevail
[18:52:07] <cartman> or BSD ;)
[18:52:31] <iive> cartman: i didn't quite get what's the problem with gpl?
[18:52:55] <cartman> iive: it has weird restrictions like this, RMS gets a stake somehow too
[18:53:13] <iive> cartman: what restriction?
[18:53:18] <mru> cartman: the appstore problem is a figment of rms' imagination
[18:53:20] <cartman> iive: AppStore vs GPL
[18:53:42] <iive> cartman: url?
[18:53:58] <mru> apparently the appstore displays some boilerplate eula whenever you download anything
[18:54:01] <cartman> iive: http://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement
[18:54:12] <mru> and this is of course not compatible with gpl
[18:54:16] <mru> but that doesn't matter
[18:54:36] <mru> apple don't the right to alter the license terms of software the don't own
[18:54:41] <mru> they don't own vlc
[18:54:44] <funman> cartman: http://geekz.co.uk/lovesraymond/archive/gpl-3-democracy
[18:55:02] <mru> thus anything they might try to apply won't stick
[18:55:21] <cartman> funman: lol
[18:58:15] <iive> cartman: apple is not compatible with freedom.
[18:59:05] <iive> It's not gpl problem, it's just how apple do their business.
[18:59:28] <cartman> well if the authors of an app is OK with it its not FSF's busines
[18:59:30] <cartman> +s
[18:59:53] <iive> there is reason android is getting so popular.
[19:00:35] <cartman> Android is good
[19:00:38] <cartman> Google is evil
[19:00:42] <cartman> as evil as Apple
[19:00:50] <iive> no, not yet.
[19:00:55] <mru> I have no idea what evil agenda they might have
[19:01:01] <mru> but their products work well
[19:01:07] <mru> I can't say that about apple
[19:01:29] <mru> and they don't dictate how people are to use their products
[19:01:45] <iive> mru: i guess you tried to program for apple platform, and that's sin!
[19:02:17] <mru> pre-osx macs would crash if I entered the same room
[19:02:27] <mru> osx is just obnoxious
[19:02:34] <cartman> Apple's products are nice too
[19:02:38] <cartman> too bad they are evilest
[19:03:15] <mru> I find them impossible to use
[19:03:37] <cartman> OSX is pretty
[19:03:48] <mru> yes, it is pretty
[19:03:54] <mru> but it's not very useful
[19:03:56] <cartman> and works for me :P
[19:08:12] <iive> i've heard that apple products are like roads in a forest. It makes good road to do the stuff you usually do, make it good and easy to go. But if you want to get off the road and do something else
[19:08:17] <iive> you hit a tree.
[19:09:57] <_av500_> an apple tree?
[19:13:07] <iive> most probably
[19:13:47] <lu_zero> android is something that works to a point
[19:14:24] <lu_zero> but I can say the same for iphone
[19:14:25] <_av500_> as everything else
[19:14:41] <lu_zero> coding for them is a complementar nightmare
[19:15:04] <cartman> Eclipse + java is as bad as it gets
[19:15:17] <lu_zero> cartman: I'm not using them
[19:15:26] <cartman> I meant for programming Android
[19:15:32] <lu_zero> I'm not using them
[19:15:42] <_av500_> cartman:i use make
[19:15:46] <cartman> yeah ok that makes you and well you
[19:16:00] * lu_zero uses make as well
[19:16:03] <lu_zero> (and ant)
[19:16:07] <lu_zero> (and adb)
[19:16:11] <cartman> your ability to miss the point is great ;)
[19:16:18] <cartman> you use crap java in the end
[19:16:22] <lu_zero> cartman: NO
[19:16:30] <cartman> you use NDK ok beats me
[19:16:31] <cartman> :P
[19:16:53] <lu_zero> IFF the java crap were working I wouldn't spend a week trying to figure out which sdl port is not working less
[19:17:20] <cartman> in the end its low standards compared to iOS development
[19:17:23] <cartman> XCode is a breeze
[19:17:35] <cartman> clang is coming along nicely
[19:17:42] <lu_zero> cartman: I must say something on that as well
[19:17:54] <lu_zero> since the simulator is a joke
[19:18:31] <_av500_> which one?
[19:18:38] <cartman> Android simulator doesn't work right with WV800 resolution for me
[19:18:48] <cartman> starts with wrong resolution sometimes
[19:18:53] <lu_zero> android has a full emulator...
[19:18:56] <_av500_> android sim sucks
[19:18:59] <lu_zero> iphone a...
[19:19:01] <_av500_> big time
[19:19:07] <cartman> _av500_: agreed
[19:19:08] <_av500_> lu_zero: i prefer the iphone one
[19:19:11] <lu_zero> ...x86 port with stub libs
[19:19:33] <_av500_> its how we did our prod dev in the past, compile for arm and x86
[19:19:39] <cartman> anyhow too hot in this room! bye!
[19:19:39] <_av500_> that forces you to write clean code :)
[19:20:10] <lu_zero> _av500_: neon asm isn't that well supported ^^;
[19:20:29] <_av500_> in the emu? its armv5 iirc
[19:20:44] <lu_zero> qemu supports neon quite well
[19:20:50] <_av500_> not the one i tried
[19:21:00] <_av500_> it just barfedd on the 1st neon i gave it
[19:21:10] <_av500_> that was like 6mo ago..
[19:21:14] <lu_zero> uhmm
[19:21:15] <_av500_> might have changed
[19:21:26] <lu_zero> qemu changes _quite_ quickly
[19:21:32] <_av500_> lu_zero: i gve it a yuv420 to 422
[19:21:39] <_av500_> and it just crashed
[19:21:45] <mru> the qemu bugs change quickly
[19:21:51] <lu_zero> mru: indeed
[19:22:01] <mru> there is no qemu with correct neon emulation
[19:22:08] <_av500_> see
[19:22:32] <_av500_> mru: hence the idea of a gumstick in the express card slot :)
[19:22:37] <_av500_> your
[19:22:45] <lu_zero> theheh
[19:22:46] <mru> yeah
[19:22:49] <mru> it would fit
[19:22:58] <lu_zero> might be interesting
[19:23:12] <_av500_> you can ducktape a bb to your vaio
[19:23:12] <mru> can expresscard "shells" be obtained easily?
[19:23:27] <mru> I have one on the table next to it
[19:23:27] <_av500_> mru: buy some crap usb3.0 host and gut it :)
[19:23:38] <mru> I was consider that option
[19:23:53] <_av500_> thn solder vcc and 4 wires for usb
[19:25:28] <mru> bonus points for including an hdmi port
[19:25:56] <_av500_> your laptop has hdmi input?
[19:26:27] <mru> of course not
[19:26:54] <_av500_> if you have an external monitor, you can use a bb as well
[19:27:11] <_av500_> the monitor is quite larger
[19:27:36] <_av500_>  bonus points for a fake framebuffer that gets read back to the host via the pciE :)
[19:28:09] <mru> or a pcie busmaster writing to the host framebuffer
[19:28:57] * _av500_ decides to take a photo of the moon
[19:30:21] <funman> _av500_: check out jupiter!
[19:30:41] <mru> svn co jupiter?
[19:30:47] <_av500_> no telescope here
[19:31:40] <mru> bad weather for moon photos here
[19:31:49] <mru> too much of something in the air
[19:43:15] <bcoudurier> hey guys\
[19:46:49] <mru> adding a typo to the scripted greeting, clever
[19:47:07] <bcoudurier> I just mistyped :/
[19:47:45] <bcoudurier> hey mru, sup ?
[19:48:01] <mru> just the usual trolling
[19:52:08] <BBB> how random can a random greeting script really get?
[19:52:16] <BBB> hi bcoudurier :)
[19:54:26] <_av500_> there: http://www.flickr.com/photos/av500/5008917453/
[19:55:45] <funman> nice!
[19:56:03] <funman> can you photograph the dark side of the moon too? (i imagine with a flash it can be possible)
[19:56:21] <peloverde> BBB: You might want to mention gcc loop unrolling and split sections in your defense of yasmification
[19:56:51] <mru> funman: easy, just wait for a new moon
[19:57:05] <mru> then the dark side is facing earth, and photographing it is easy
[19:57:36] <mru> the earthlight is sufficient
[20:01:17] <DonDiego> _av500_: ah, i see plenty proof of your forking :)
[20:01:58] <_av500_> yep
[20:02:04] <jannau> _av500_: congrats
[20:02:08] <_av500_> thx
[20:02:17] <_av500_> funman: http://www.flickr.com/photos/av500/5008940349/
[20:02:40] <BBB> peloverde: can't you just jump in and say "I like yasm better"?
[20:02:41] <BBB> :-p
[20:02:42] * cartman goes and look for the kids instead
[20:02:48] <BBB> peloverde: and what are you working on now?
[20:02:51] <jannau> I guess I'm allowed to 'guess' what http://www.flickr.com/photos/av500/4967965846/in/photostream/ is
[20:03:05] <mru> _av500_: did you make absolutely certain it isn't a spork?
[20:03:16] <funman> mru: the dark side is facing earth??
[20:03:28] <cartman> av500: he heeee nice kids!
[20:03:36] <_av500_> jannau: yeah
[20:03:41] <mru> funman: the dark side is whichever isn't sunlit
[20:03:46] <jannau> _av500_: +not
[20:03:46] <funman> _av500_: this is not enough to photograph jupiter?
[20:03:49] <funman> oh right
[20:03:56] <_av500_> jannau: what happening to janneg? you ate him?
[20:03:57] <mru> you're confusing it with the _back_ side
[20:04:05] <mru> that's much harder to see
[20:04:12] <funman> not the 'hidden' side?
[20:04:23] <mru> although slightly more than half of the total can be seen from earth
[20:04:28] <_av500_> funman: my astronomy knowledge: i know the moon and .... i ... know....the moon
[20:04:37] <mru> due to the moon wobbling ever so slightly
[20:04:38] <funman> 'far' side it seems
[20:04:51] <mru> far side will do
[20:05:12] <funman> _av500_: these days jupiter is very bright because earth is just between it and the sun
[20:05:15] <peloverde> BBB: I'm working on nothing, maybe some blogging, my real computer is in my car underneath everything I own, I don't move into my new place until tomorrow
[20:05:26] <funman> dunno how it'd look without a telescope though
[20:05:28] <BBB> aiyoh
[20:05:32] <jannau> _av500_: just my alternate nick and I haven't changed it back after freenode hickup
[20:05:40] <BBB> peloverde: where are you moving to, and I mean what kind of job did you take?
[20:06:14] <_av500_> funman: unless it is visible from my bierbank right now, it does not exist
[20:06:36] <peloverde> moving to san jose, this job http://zoran.com/Digital-Cameras
[20:06:57] <BBB> zoran!!! omg
[20:07:11] <_av500_> peloverde: you'll make cheap chinese digicams?
[20:07:13] <BBB> my first free software ever was a zoran kernel driver :-p
[20:07:23] <_av500_> peloverde: we can do business together :)
[20:07:54] <peloverde> They make the flip which seems to be pretty popular
[20:08:55] <_av500_> right
[20:35:27] <astrange> flip looks like another device set to be completely destroyed by cell phone convergence
[21:03:13] <_av500_> astrange: no
[21:03:51] <_av500_> flip=cheap, no contract etc..
[21:04:07] <_av500_> buy it, use at the beach, lose it, dont care
[21:04:10] <_av500_> not like a phone
[21:04:42] <astrange> just don't lose your phone
[21:05:15] <astrange> ipod touch is contractless too and at some point facebook video upload or etc. (i think it does that) is better than a larger actual camera
[21:06:11] <_av500_> yes, touch is a better contender
[21:07:17] <_av500_> i guess ppl like the flip for the 1 button UI
[21:48:59] <CIA-63> ffmpeg: stefano * r25149 /trunk/ (cmdutils.c ffmpeg.c cmdutils.h): Move log_callback_help to cmdutils.[hc], for allowing sharing.
[21:51:37] <CIA-63> ffmpeg: mru * r25150 /trunk/libavcodec/arm/asm.S:
[21:51:37] <CIA-63> ffmpeg: ARM: disable movw/movt for relocated values on Apple platforms
[21:51:37] <CIA-63> ffmpeg: Apparently Apple platforms do not handle movw/movt relocations
[21:51:37] <CIA-63> ffmpeg: properly, leading to runtime crashes in code using them.
[21:52:23] <roxfan> apple uses like five relocs on arm...
[21:53:46] <mru> would be much nicer if the linker complained
[21:53:52] <roxfan> heh
[21:54:26] <astrange> macho runs out of space in the reloc flags field very fast
[21:54:42] <astrange> not sure why they didn't change the format to increase it, there were several opportunities
[21:54:53] <astrange> well, besides that they don't like relocs
[21:55:07] <mru> they like to suck
[21:56:56] <DonDiego> isn't there a way to detect this?
[21:57:03] <DonDiego> __APPLE__ is very ugly..
[21:57:03] <mru> no
[21:57:10] <mru> linker succeeds
[21:57:16] <mru> runtime crash
[21:59:31] <peloverde> http://spectralhole.blogspot.com/2010/09/aac-bistream-flaws-part-2-aac-960-zero.html
[22:15:05] <Dark_Shikari> found a bug in the error concealment in h264 for missing frames
[22:15:13] <Dark_Shikari> at least in this stream (p-frames only, so very simple)
[22:15:18] <Dark_Shikari> frame 19 is missing
[22:15:26] <Dark_Shikari> so at frame 20, it runs the loop that processes mmcos from previous frames
[22:15:31] <Dark_Shikari> ref list before:
[22:15:34] <Dark_Shikari> 18, 17, 16.... 4
[22:15:46] <Dark_Shikari> ref list that we want after: N, 18, 17, 16... 5
[22:15:49] <Dark_Shikari> where N is our missing frame that we don't have
[22:15:54] <Dark_Shikari> what we probably should do: 18, 18, 17, 16...
[22:16:00] <Dark_Shikari> what ffmpeg does: 4, 18, 17, 16... (LOL)
[22:16:08] <mru> rotate ftw
[22:16:38] <Dark_Shikari> my boss dubbed it the "time warp"
[22:16:50] <mru> heh
[22:18:40] <Dark_Shikari> hack to fix it: http://pastebin.com/phH8b40T
[22:19:18] <Dark_Shikari> if michael cares to actually fix it  (unlikely, he's lazy as fuck these days and spends all his time complaining about people doing actual work, like yasmification)
[22:19:24] <Dark_Shikari> http://www.mediafire.com/?b18akxj5ea1s814 here is the file
[22:19:36] <Dark_Shikari> frame 19 is missing.  5 frames later, the encoder corrects for the error via reference invalidation
[22:33:50] <bcoudurier> what does yasm fix ?
[22:33:57] <mru> gcc
[22:35:13] <Dark_Shikari> 1) makes code more maintainable
[22:35:16] <Dark_Shikari> 2) adds win64 support
[22:35:24] <Dark_Shikari> 3) makes code faster (less gcc stupidity interrupting things)
[22:35:35] <Dark_Shikari> 4) adds more optimization posssibilities
[22:35:46] <Dark_Shikari> 5) makes it much easier to template code (e.g. for mmx vs sse2 vs ssse3)
[22:36:00] <mru> I don't understand this templating thing
[22:36:21] <mru> isn't the point of sseN+1 that it can do things sseN couldn't?
[22:36:26] <Dark_Shikari> Yes
[22:36:28] <Dark_Shikari> So here's an example
[22:36:38] <mru> so what is there to template?
[22:36:39] <Dark_Shikari> in mmx/sse2, you do absolute value as follows:
[22:36:47] <Dark_Shikari> mov tmp, reg
[22:36:53] <Dark_Shikari> or er
[22:36:54] <Dark_Shikari> it's
[22:36:56] <Dark_Shikari> xor tmp, tmp
[22:37:00] <Dark_Shikari> sub tmp, reg
[22:37:05] <Dark_Shikari> max tmp, reg
[22:37:07] <mru> similarly shaped instructions with different widths wuld be one case
[22:37:09] <Dark_Shikari> that's 3 instructions
[22:37:14] <Dark_Shikari> in ssse3, you have pabsw
[22:37:18] <Dark_Shikari> 1 instruction
[22:37:23] <Dark_Shikari> thus, in your code, you use
[22:37:26] <mru> for things that have both with 8 and 16 versions
[22:37:27] <Dark_Shikari> PABSW reg, tmp
[22:37:37] <Dark_Shikari> in the mmx/sse2 versions, PABSW is a macro that does 3 instructions.
[22:37:45] <Dark_Shikari> in the ssse3 version, it maps to pabsw.
[22:38:04] <Dark_Shikari> thus, to do this, you'd do something like this
[22:38:10] <Dark_Shikari> %macro MYFUNC <stuff> %endmacro
[22:38:17] <Dark_Shikari> %define PABSW PABSW_MMX
[22:38:20] <Dark_Shikari> MYFUNC sse2
[22:38:29] <Dark_Shikari> %define PABSW PABSW_SSSE3
[22:38:33] <Dark_Shikari> MYFUNC ssse3
[22:38:38] <Dark_Shikari> now you have two versions, one with the sse2 absolute value method
[22:38:40] <Dark_Shikari> and one with ssse3.
[22:38:44] <mru> ok, that works when a new instruction maps to a common sequence of old instructions
[22:38:54] <Dark_Shikari> That's one example
[22:38:57] <Dark_Shikari> Now, the other case is size.
[22:39:17] <Dark_Shikari> Let's take the simplest possible function: one that writes zeroes to an output buffer.
[22:39:20] <bcoudurier> what does cglobal do in yasm ?
[22:39:27] <Dark_Shikari> bcoudurier: declare a function
[22:39:30] <bcoudurier> does that declare a global symbol ?
[22:39:31] <Dark_Shikari> so simplest output function
[22:39:36] <Dark_Shikari> pxor m0, m0
[22:39:40] <Dark_Shikari> .loop:
[22:39:47] <Dark_Shikari> mova [output], m0
[22:39:52] <Dark_Shikari> add output, 16
[22:39:54] <Dark_Shikari> cmp output, end
[22:39:57] <Dark_Shikari> jl .loop
[22:40:05] <Dark_Shikari> you can see what it does.
[22:40:16] <Dark_Shikari> now, suppose we want to declare an mmx width-8 and sse width-16 at the same time.
[22:40:17] <bcoudurier> it seems all cglobal are prefixed with ff_
[22:40:23] <Dark_Shikari> We change "add output, 16" to "add output, mmsize"
[22:40:27] <Dark_Shikari> and we do
[22:40:28] <Dark_Shikari> INIT_MMX
[22:40:31] <Dark_Shikari> MYFUNC mmx
[22:40:32] <Dark_Shikari> INIT_XMM
[22:40:34] <Dark_Shikari> MYFUNC sse2
[22:40:42] <Dark_Shikari> now we have a width-8 version, and a width-16 version.
[22:40:49] <Dark_Shikari> bcoudurier: yes, cglobal auto-prefixes.
[22:41:19] <bcoudurier> how do you define static funcs ?
[22:42:11] <Dark_Shikari> you mean locally-accessible-only?
[22:42:15] <bcoudurier> yes
[22:42:17] <Dark_Shikari> why would you need to?
[22:42:18] <Dark_Shikari> this isn't C
[22:42:30] <Dark_Shikari> you don't get optimization benefits from static
[22:42:43] <bcoudurier> you don't want to export them
[22:42:52] <mru> and the most bizarre part of the discussion:
[22:43:07] <Dark_Shikari> bcoudurier: they get stripped anyways
[22:43:11] <mru> [rant against yasm, rant, rant, rant]
[22:43:16] <mru> [I suggested using nasm once]
[22:43:28] <mru> [rant against yasm, inline is the way]
[22:43:30] <bcoudurier> I don't care if people prefer it
[22:43:36] <Dark_Shikari> mru: nasm and yasm are the same language
[22:43:40] <mru> I know
[22:43:42] <Dark_Shikari> that's like saying "C is crappy, you should use ICC"
[22:44:00] <bcoudurier> if there is a "need" that's cool, but translating for the sake of it seems useless to me
[22:44:15] <mru> Dark_Shikari: michael claims he once suggested we should use nasm/yasm
[22:44:26] <mru> yet he misses no opportunity to rail against it
[22:44:35] <Dark_Shikari> ah
[22:44:37] <Dark_Shikari> well that's michael
[22:44:38] <bcoudurier> he doesn't like it
[22:44:40] <Dark_Shikari> bcoudurier: it fixes win64
[22:44:44] <Dark_Shikari> it makes it easier to optimize old asm
[22:45:18] <bcoudurier> at least he seems to not like it
[22:45:19] <mru> all intermixed with random fud about call overhead
[22:45:34] <mru> it doesn't matter whether or not he likes it
[22:45:36] <Dark_Shikari> bcoudurier: michael doesn't like anything he didn't write
[22:45:40] <mru> he hasn't touched the code for years
[22:45:55] <bcoudurier> nobody AFAIK
[22:46:06] <bcoudurier> and translating is not touching IMHO
[22:46:21] <bcoudurier> besides if he is the maintainer I can understand
[22:46:23] <Dark_Shikari> the translation usually involves optimization
[22:46:28] <Dark_Shikari> most functions have gotten faster
[22:46:30] <mru> he's not maintaining
[22:46:32] <Dark_Shikari> iirc h264 decoding has gotten 1% faster
[22:46:38] <bcoudurier> that said, win64 should work
[22:47:03] <bcoudurier> well I don't like exporting all the fucking yasm functions
[22:47:12] <mru> so don't
[22:47:18] <bcoudurier> then don't do cglobal ?
[22:47:26] <Dark_Shikari> strip -x
[22:47:26] <Dark_Shikari> done
[22:47:28] <bcoudurier> inline asm means you can declare them static
[22:47:32] <Dark_Shikari> strip -x
[22:47:32] <Dark_Shikari> done
[22:47:42] <bcoudurier> nah strip is not the solution
[22:47:49] <Dark_Shikari> It's a one line solution that fixes it
[22:47:53] <Dark_Shikari> why do anything more complicated?
[22:47:59] <mru> Dark_Shikari: can't you have a function without using cglobal?
[22:48:11] <Dark_Shikari> Yes
[22:48:13] <Dark_Shikari> Easily
[22:48:23] <Dark_Shikari> Just put down a label.
[22:48:33] <mru> good, what I though
[22:48:35] <Dark_Shikari> It's generally not suitable for complicated stuff that does lots of stack access
[22:48:39] <Dark_Shikari> because the macro system wasn't built to handle that
[22:48:56] <Dark_Shikari> well, like, for example
[22:49:02] <Dark_Shikari> in x264, the CABAC functions share a single set of end code
[22:49:18] <Dark_Shikari> jmp cabac_putbyte
[22:49:35] <Dark_Shikari> and cabac_putbyte is another, non-global function
[22:49:49] <Dark_Shikari> in fact, it's even more complicated than that -- we do something there that is IMPOSSIBLE in C.
[22:50:01] <Dark_Shikari> we call cabac_putbyte, and then at the end, to save code size....
[22:50:03] <Dark_Shikari> jmp mangle(x264_cabac_encode_decision_asm.update_queue_low)
[22:50:08] <Dark_Shikari> we jump back into one of the previous cabac functions
[22:50:20] <Dark_Shikari> Yes you could do it with gotos, but not if it was a separate function.
[22:50:28] <Dark_Shikari> And the file has a ton of separate functions which are sharing some code.
[22:54:42] <mru> a compiler could theoretically do that
[22:55:00] <Dark_Shikari> In theory, a compiler can output any asm
[22:55:01] <mru> if it noticed functions sharing a common tail
[22:55:07] <Dark_Shikari> however, there is no syntax in C to *signal* that to a compiler.
[23:10:35] <peloverde> gah, mike's wiki is down
[23:11:00] <peloverde> Have people ever discussed merging with the videolan wiki?
[23:11:16] <BBB> not that I know
[23:13:24] <peloverde> It seems like there is some overlap and you could wind up with a result that is more robust, more complete, and better updated (I've been frustrated about mike's version of mediawiki being old a few times)
[23:14:00] <BBB> maybe mike is getting a little old
[23:14:35] <Dark_Shikari> we can have the combined free multimedia wiki
[23:14:37] <Dark_Shikari> ffmpeg, x264, vlc
[23:44:47] <peloverde> Is it worth adding the one real and 3 broken streams that test the AAC channel model to fate? I don't see anyone touching that code anytime soon but the kinds of brokenness out there we support are quite wonky and varied
[23:54:15] <bcoudurier> humm