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

[irc at mansr.com]

[00:09:30] <SmkMnstr> got ffmpeg linking with my app in linux & windows
[00:14:46] <ramiro> nice flamebait from AzureSky in issue1162...
[00:16:22] <ramiro> SmkMnstr: mind I ask, what app is it?
[03:31:14] <Compn> ehe
[03:31:54] <Compn> i had to reply to troll, just in case any people got trolled, we'd be flooded by 'why u so mean?' questions if it were posted to slashdot...
[03:35:43] <Dark_Shikari> he'd be mocked on slashdot
[03:35:46] <Dark_Shikari> ffs he bragged about his iq
[03:40:06] <Dark_Shikari> mru:  __asm__ volatile ("bl __aeabi_idivmod
[03:40:08] <Dark_Shikari> is that portable?
[03:40:11] <Dark_Shikari> that looks compiler-specific
[03:44:09] <ohsix> its part of the abi
[03:45:59] <Compn> Dark_Shikari : stupid trolls get bites too
[03:46:00] <Dark_Shikari> wow, so the abi defines the name of functions like that?
[03:46:16] <Compn> how is babby formed?
[03:54:35] <kierank> licensing is hard. lets go shopping
[05:30:40] <pJok> god morgon kshishkov :)
[07:14:02] <KotH> en wunderschöne guete morge!
[07:15:55] <kshishkov> in some places
[07:16:47] <KotH> a good morning begins in your head
[07:16:50] <KotH> ;)
[07:17:10] <kshishkov> guess what messes with my head in the first place
[07:20:27] <KotH> your brain?
[07:20:38] <kshishkov> no, local environment
[07:20:57] <KotH> you cannot change your enviroment, without first changing yourself
[07:21:38] <hyc> how very zen
[07:21:44] <kshishkov> circumcision?
[07:22:24] <KotH> might be a way, but i wouldnt start with a lobotomy
[07:25:20] <CIA-81> ffmpeg: thardin * r22846 /trunk/libavformat/movenc.c: Predicting the size of the hdlr, string data and trkn tags in the MOV muxer
[07:26:21] <superdump> morning
[07:26:30] <kshishkov> morrow
[07:38:39] <av500> 'ng
[07:39:48] <kshishkov> learn how to speak
[07:40:29] <KotH> ze jermans könt spiiik
[07:41:42] <kshishkov> indeed, but German words may scare even Finns
[07:44:41] <av500> jetzt hab dich nicht so
[07:45:17] <kshishkov> not really
[07:45:33] <kshishkov> Russian language is a poor cousin of German language
[07:46:22] <KotH> av500: i think we should teach kshishkov some german :)
[07:46:37] <av500> "Papiere bitte!"
[07:49:31] <kshishkov> KotH: I mentioned it several times that I have rather good German accent
[07:52:47] * av500 larts theorarm for requiring libogg
[07:53:33] <kshishkov> but Ogg and Theora is like communism and Lenin!
[07:56:06] <kshishkov> (or XML and Java)
[07:56:31] <Dark_Shikari> open sores is communism!1!!
[07:56:33] <peloverde> What always bugs me about these theora articles is the way they frame things they imply that there is no open source implementation of the standard codecs
[07:57:04] <kshishkov> peloverde: maybe because theraplay can't handle h264+aac
[07:57:29] <peloverde> theraplay?
[07:58:03] <kshishkov> err, default theora player shipped with libtheora
[07:58:04] <KotH> there is no opensource implementation! there is no reference code!
[07:58:07] <KotH> ^^'
[08:42:42] <superdump> peloverde: seen that sample someone posted about the ugly transitions?
[08:44:03] <Yuvi> mru: btw, ffvorbis is 2x faster than tremor on a8
[08:44:41] <kshishkov> Yuvi: that does not matter, FFmpeg does not exist it their eyes
[08:45:06] <Yuvi> just congratulating him ;)
[08:45:33] <Yuvi> it's about even on arm11 if anyone cares enough about that to write a ton of vfp
[08:47:42] <andoma> I don't think VFP is much faster than normal FPU code, it's just a bit more compact
[08:50:02] <Yuvi> I'd think should be able to use its vector mode for some speedup, but I haven't looked at it too closely (other than that it's depreciated in favor of neon simd going forward)
[08:54:01] <andoma> I think the only speedup you would gain is lower pressure on the I-cache
[08:54:46] <andoma> AFAIK the VFP instructions basically loops multiple FPU instructions to "emulate" some kind of vector behaviour
[08:54:53] <andoma> but i think MÃ¥ns knows all the details
[09:06:23] <Yuvi> looks like it, but it also looks like you can't keep multiple vfp pipelines fully busy unless you use short vectors
[09:07:05] <Yuvi> so there's some room for improvement over compilers
[09:13:54] <peloverde> superdump, yes
[09:14:54] <superdump> and? are there really audible artifacts because of the transitions? :)
[09:14:58] <superdump> or is the file just garbage
[09:15:00] <superdump> ?
[09:53:27] <peloverde> I haven't actually looked at the file
[09:54:28] <peloverde> my guess is that it isn't actually an audible artifact from the window transition but I have yet to verify
[09:54:40] <peloverde> I've been trying to iron the last few bugs out of the ps decorrelator
[09:57:43] <superdump> :)
[09:58:15] <kshishkov> well, maybe your PS work makes AAC encoder usable as a side effect
[09:58:27] <superdump> umm
[10:02:42] <kshishkov> superdump, you should remember certain consequences of your work on AMR-NB
[10:41:11] <mru> andoma: vfp vector ops are not truly parallel, but you can carry on doing integer stuff while it executes in the background
[10:43:17] <kshishkov> that's what coprocessors are for!
[10:44:42] * kshishkov remembers x87 and shudders
[10:45:04] <thresh> copro-cessors?
[10:45:48] <kshishkov> in case of Intel - yes
[10:46:02] <thresh> moroning, btw
[10:47:02] <kshishkov> it's too late for that
[10:48:30] <mru> not here
[10:50:01] <kshishkov> wait a bit then
[11:15:37] <CIA-81> ffmpeg: mru * r22847 /trunk/libavcodec/dca.c: DCA: use some type-punning in qmf_32_subbands()
[11:15:40] <CIA-81> ffmpeg: mru * r22848 /trunk/libavcodec/dca.c:
[11:15:40] <CIA-81> ffmpeg: DCA: use a local variable for loop boundary
[11:15:40] <CIA-81> ffmpeg: This prevents gcc reloading the value from memory on each iteration
[11:15:40] <CIA-81> ffmpeg: of the loop.
[11:15:40] <CIA-81> ffmpeg: mru * r22849 /trunk/libavcodec/ (dcadata.h dca.c):
[11:15:41] <CIA-81> ffmpeg: DCA: simplify lfe_interpolation_fir()
[11:15:42] <CIA-81> ffmpeg: This reorders the lfe_fir tables, and drops the mirrored half,
[11:15:42] <CIA-81> ffmpeg: such that the loops in lfe_interpolation_fir() can be simplified.
[11:15:43] <CIA-81> ffmpeg: The new loop structure should be easier to implement with SIMD.
[11:15:43] <CIA-81> ffmpeg: Static data size is reduced by 2kB.
[11:15:44] <CIA-81> ffmpeg: 3% faster on Cortex-A8.
[11:28:32] <CIA-81> ffmpeg: diego * r22850 /trunk/doc/general.texi: Fix extra object path in Solaris section.
[12:00:58] <av500> hmm, FFMPEG_VERSION is not exported in lavf, lavc?
[12:01:28] <mru> seems not
[12:01:54] <mru> patches welcome I guess
[12:01:58] <av500> :)
[12:02:15] <av500> atm it does not work for me anyway, as my tgz snapshots dont get it...
[12:03:07] <av500> so it is "UNKNOWN" :(
[12:27:11] <pentanol> hello :)
[12:28:14] <pentanol> anybody knows, how watermark actually should work? i.e if I tries change everyone picture from video stream by algorithm dugad or cox, it can be right? or I should involve another picture here and how it compute then?
[12:29:06] <pentanol> I've seen this http://thread.gmane.org/gmane.comp.video.ffmpeg.user/5959/focus=5960 and that http://thread.gmane.org/gmane.comp.video.ffmpeg.user/11625 and this confuse me
[13:22:34] <CIA-81> ffmpeg: jai_menon * r22851 /trunk/libavcodec/alacenc.c: Remove useless header inclusion.
[13:29:49] <CIA-81> ffmpeg: mru * r22852 /trunk/libavcodec/arm/synth_filter_neon.S: ARM: fix NEON synth_filter_float with hardfp calls
[13:54:35] <BBB> we should really buy vitor more beer, he's genious
[15:04:20] <CIA-81> ffmpeg: cehoyos * r22853 /trunk/libavformat/aviobuf.c:
[15:04:20] <CIA-81> ffmpeg: Do not set pos to an error value.
[15:04:20] <CIA-81> ffmpeg: Patch by Howard Chu, hyc highlandsun com
[15:17:41] <CIA-81> ffmpeg: diego * r22854 /trunk/doc/general.texi:
[15:17:41] <CIA-81> ffmpeg: Add DOS section to the platform documentation.
[15:17:41] <CIA-81> ffmpeg: patch by Michael Kostylev, michael.kostylev gmail com
[16:05:59] <CIA-81> ffmpeg: mru * r22855 /trunk/libavcodec/dca.c: DCA: use FASTDIV in decode_blockcode()
[16:17:34] <CIA-81> ffmpeg: benoit * r22856 /trunk/libavcodec/huffyuv.c:
[16:17:34] <CIA-81> ffmpeg: Extradata length checks for Huffyuv.
[16:17:34] <CIA-81> ffmpeg: Patch by Michael Kaufmann hallo $(name) dash $(surname) ch
[17:44:21] <elenril> Yuvi: ping
[18:51:03] <stupid> @mru : Does ffmpeg runs any codes on DSP ? I want  to port some part of mplayer on dsp so that mplayer can use both ARM & DSP for video decoding
[18:51:14] <kshishkov> it doesn't
[18:51:36] <j-b> I want a poney too
[18:52:05] <kshishkov> take Citroen 2CV instead
[18:52:17] <bilboed> a poney pulling a 2CV filled with mars bars
[18:52:20] <stupid> HI ALL : Does ffmpeg runs any codes on DSP ? I want  to port some part of mplayer on dsp so that mplayer can use both ARM & DSP for video decoding
[18:52:34] <hyc> stupid: you already got your answer
[18:52:52] <kshishkov> and appropriate nick for repeating that question
[18:53:06] <hyc> besides, you haven't said *which* DSP...
[18:53:27] <kshishkov> C64 most probably
[18:53:46] * twnqx` has a defective C64 straight in front of him
[18:53:48] <kshishkov> the answer is still no
[18:53:53] <hyc> lol
[18:53:56] <SmkMnstr> if so yes i believe ffmpeg has c64+ and NEON codec impls
[18:54:06] <hyc> c64 only if it's TI
[18:54:06] <SmkMnstr> ah no?  u sure?
[18:54:18] <hyc> and no, ffmpeg only does NEON
[18:54:37] <SmkMnstr> hm theres also dvsdk
[18:54:48] <j-b> Use OpenMax IL on DSPs, if you are lucky
[18:55:00] <stupid> I am using C64DSP on beagleboard
[18:55:15] <stupid> hyc : i am usign C64+ DSP on beagleboard
[18:55:34] <hyc> I hear an echo in here
[18:55:43] <stupid> I already ported mplayer on Android. I activated DSPLINK drivers in there
[18:55:57] <kshishkov> I'm not a prophet of MÃ¥ns but I believe he spake that TI C64+ compiler was hard to interface so no C64+ DSP support in FFMpeg
[18:56:13] <stupid> I want to know exactly which codes do i need to port
[18:56:26] <hyc> I asked mru about this back in Auguest/September
[18:56:28] * elenril gives hyc a clue stick
[18:56:41] <jai> elenril: cluebat works better
[18:56:54] <j-b> Doesn't beagleboard has OpenMax IL ?
[18:57:17] <hyc> OpenMax is kind of a mess to build
[18:57:23] <bilboed> s/to build//
[18:57:30] <stupid> No android doesn't uses that .. Bt i ported mplayer and tested it there
[18:57:36] <kshishkov> and so will be FFmpeg with DSP support
[18:58:15] <hyc> took me days to get it all to build for my AI TouchBook, and it still didn't run properly in the end
[18:58:42] <hyc> AI TouchBook is derived from an early rev Beagleboard...
[18:58:46] <kshishkov> maybe you should've used crosscompiler
[18:58:59] <stupid> @kshishkov : Could you please tell me exactly which codes do I need to port on DSP
[18:59:27] <kshishkov> stupid: probably decoders and functions from dsputil
[18:59:50] <hyc> yes, I was crosscompiling from my laptop, the time was mostly from obtaining consistent source code
[19:00:20] <SmkMnstr> ive been gearing up to use ffmpeg, but now i need to be more aware of openmax
[19:00:21] <hyc> there were 3 different TI web sites offering the code, 2 of them were obsolete
[19:01:50] <kshishkov> so what? none of them worked at the end for you
[19:02:21] <hyc> well, I sent a couple patches back to the maintainers after I got it close
[19:02:36] <hyc> but yeah, mostly a waste of time
[19:02:52] <kshishkov> that's why I develop FFmpeg instead
[19:03:01] <hyc> should've ended this conversation at "I want a pony"
[19:04:23] * kshishkov wonders why ponies are so popular
[19:04:47] <SmkMnstr> how much resources does it take to stream a/v from a beagle?
[19:05:04] <kshishkov> three
[19:05:07] <SmkMnstr> from a webcam/mic
[19:05:08] <hyc> dunno. comes from some stereotype of little girls saying "I want a pony for christmas"
[19:05:15] <SmkMnstr> u can tell me size/bitrate and cpu%
[19:05:26] <SmkMnstr> framerate, etc whatev relevant
[19:05:47] <hyc> SmkMnstr: stream what a/v?
[19:05:49] <kshishkov> you'd better try it and measure
[19:05:57] <SmkMnstr> well i will soon enough
[19:06:26] <kshishkov> some cpu may be eaten by USB/network stuff
[19:06:58] <SmkMnstr> i wont actually have my gizmos up for another month or so
[19:07:11] <SmkMnstr> anxiously awaiting their shipment
[19:07:18] <hyc> playing hulu live on the TouchBook is a near thing
[19:07:25] <hyc> rtmpdump takes 1-2% CPU
[19:07:34] <SmkMnstr> in the meantime i have a cross platform build tree im preparing for the day i have gizmos
[19:07:48] <hyc> mplayer takes ~85% CPU on average, for 512x288 VP6
[19:07:50] <kshishkov> hyc: it takes 0% on any CPU here :P
[19:08:15] <hyc> 400kbps
[19:08:54] <hyc> kshishkov: eh? I haven't seen any accelerated VP6
[19:09:26] <kshishkov> hyc: in my case it's all accelerated by skipping it totally, including never visiting Hulu site
[19:09:42] <Yuvi> elenril: pong
[19:10:00] <hyc> well, that was the task that broguht me here in August...
[19:10:26] <elenril> Yuvi: can you review tags writing for matroska?
[19:10:53] <elenril> it's been a few weeks, i was wondering if you forgot about it
[19:10:58] <Yuvi> elenril: right, I need to get caught up with my email
[19:15:29] <elenril> no hurry, as long as it's not completely forgotten :)
[19:17:14] <Kovensky> oh, Yuvi; long time no see =p
[19:21:59] <CIA-81> ffmpeg: stefano * r22857 /trunk/libavcodec/eval.c: Remove unnecessary header inclusion directives.
[19:22:02] <CIA-81> ffmpeg: stefano * r22858 /trunk/libavcodec/ (eval.c eval.h ratecontrol.c):
[19:22:02] <CIA-81> ffmpeg: Rename ff_parse() to ff_parse_expr().
[19:22:02] <CIA-81> ffmpeg: The new name is more expressive and fits better in the overall naming
[19:22:02] <CIA-81> ffmpeg: scheme for the revisited eval API.
[19:22:02] <CIA-81> ffmpeg: stefano * r22859 /trunk/libavcodec/ (eval.c eval.h):
[19:22:02] <CIA-81> ffmpeg: Change constness for func[12]_name parameters of ff_parse_expr() and
[19:22:03] <CIA-81> ffmpeg: ff_parse_and_eval_expr().
[19:22:03] <CIA-81> ffmpeg: Change attribute from "const char **" to "const char * const *".
[19:22:04] <CIA-81> ffmpeg: The name arrays are not supposed to be changed by the function.
[19:41:28] <mru> hyc: you use vp6?
[19:42:04] <hyc> mru: we didn't have enough CPU to do H264 at the time
[19:42:36] <hyc> I haven't checked if more recent neon code does better
[19:44:04] <hyc> most stuff on hulu is still available as 400kbps VP6, in addition to 3 choices of H264 (400k, 650k, 1Mbps)
[19:44:18] <hyc> hm, 480kbps VP6
[19:44:33] <mru> what resolution are those h264 streams?
[19:45:09] <hyc> 512x288, 640x360, 720x400
[19:45:26] <mru> should play fine on omap3
[19:45:36] <mru> unless they've used insane encoding settings
[19:45:51] <hyc> it's all main profile
[19:46:02] <mru> btw, I can double the vp6 decoder speed if you ask nicely
[19:46:27] <hyc> oooo, I was just about to ask if anyone has looked at accelerating it
[19:46:43] <mru> there's some very low-hanging fruit there
[19:47:09] <hyc> but if we can use the H264 streams, they look better anyway
[19:47:17] <mru> no doubt
[19:49:37] <hyc> still I imagine there are other sites still using VP6. worth doing?
[19:50:01] <mru> I didn't think anyone still used it
[19:50:42] <hyc> I guess it's only leftover on hulu at this point
[19:51:03] <hyc> for some of the really old shows on hulu they also have 640x360 700kbps vp6
[19:51:25] <Dark_Shikari> vp6 is only really slow if you keep the postprocessors
[19:51:45] <hyc> but most of the new shows are 3 H264 streams and the 512x288 vp6
[19:58:47] <hyc> so aside from my screwup in that aviobuf.c patch, the rtmp seek patch is OK to commit
[19:59:00] <hyc> no one has said anything about the rtmp logging patch
[20:23:59] <CIA-81> ffmpeg: stefano * r22860 /trunk/libavcodec/ (eval.c eval.h): (log message trimmed)
[20:23:59] <CIA-81> ffmpeg: Fix constness for func[12] parameters in ff_parse_expr() and
[20:23:59] <CIA-81> ffmpeg: ff_parse_and_eval_expr().
[20:23:59] <CIA-81> ffmpeg: Change func[12] attributes from "** func" to "* const * func".
[20:23:59] <CIA-81> ffmpeg: This is consistent with the semantics of the provided arrays of
[20:23:59] <CIA-81> ffmpeg: functions, which are not supposed to be changed by the ff_parse_*
[20:24:00] <CIA-81> ffmpeg: functions.
[20:31:39] <mru> latest patches make dca 3.9x faster than when I started
[20:31:46] <mru> on cortex-a8
[20:32:23] <Dark_Shikari> why do we care about dca on cortex
[20:32:35] <mru> someone with money does
[20:34:04] <hyc> what's dca? :P
[20:34:16] <mru> dts without trademark
[20:38:41] <merbanan> hyc: dts coherent acoustics
[20:40:58] <Dark_Shikari> mru: another secret contract?
[20:46:22] <CIA-81> ffmpeg: mru * r22861 /trunk/libavcodec/ (dcadsp.h dca.c Makefile dcadsp.c):
[20:46:22] <CIA-81> ffmpeg: DCA: break out lfe_interpolation_fir() inner loops to a function
[20:46:22] <CIA-81> ffmpeg: This enables SIMD optimisations of this function.
[20:46:23] <CIA-81> ffmpeg: mru * r22862 /trunk/libavcodec/dcadata.h: DCA: 16-byte-align lfe_fir tables
[20:46:23] <CIA-81> ffmpeg: mru * r22863 /trunk/libavcodec/ (5 files in 2 dirs): DCA: ARM/NEON optimised lfe_fir
[20:49:12] <hyc> (thx for info)
[20:55:49] <DonDiego> moin
[20:59:42] <DonDiego> mru: what's with all those extra cflags you pass to the fate boxes?
[20:59:59] <mru> which ones?
[21:00:11] <DonDiego> --target-os=linux --arch=arm --cpu=cortex-a8 --extra-cflags='-mfpu=neon -mfloat-abi=softfp'
[21:00:15] <DonDiego> for example
[21:00:23] <DonDiego> this is necessary for the crosscompiler?
[21:00:31] <mru> those cflags are required for that compiler to do the right thing
[21:00:43] <DonDiego> yes, i expected that
[21:00:52] <DonDiego> my question is:
[21:00:54] <mru> it will still do _something_ without them
[21:00:58] <mru> so they can't be detected
[21:01:07] <DonDiego> should that stuff be in configure and/or the docs?
[21:01:31] <mru> people who don't know what to pass have no business building ffmpeg
[21:01:38] <mru> they'll screw up much worse elsewhere anyway
[21:01:46] <DonDiego> :)
[21:01:57] <DonDiego> now ease up and answer my question
[21:02:20] <mru> I don't think duplicating half the arm and gcc manuals is a good idea
[21:02:20] <DonDiego> i have almost all the rest nailed and documented now
[21:02:41] <DonDiego> ok, so it's supposed to be common knowledge?
[21:02:55] <mru> you'd better know what ABI you want to build for before building
[21:04:08] <mru> trying to enumerate all valid combinations and when to use them is pointless
[21:04:16] <mru> you should know your hardware
[21:04:19] <DonDiego> --extra-ldflags=-Tbss=0x2000000
[21:04:29] <DonDiego> that's from the blackfin box
[21:04:30] <mru> that's a dirty hack
[21:04:45] <mru> it'll build without it too
[21:04:49] <mru> and run
[21:05:20] <mru> that's just to help a bit with memory fragmentation
[21:05:32] <DonDiego> so no need to document it?
[21:05:39] <mru> no
[21:05:44] <DonDiego> ok
[21:05:47] <mru> it needs a kernel hack to work too
[21:05:55] * DonDiego scratches another box from the list
[21:06:08] <mru> and my special malloc lib
[21:06:22] <DonDiego> ok, then there's the m32/m64 issue
[21:06:29] <DonDiego> lots of fate boxes pass either flag
[21:06:47] <DonDiego> why is that?
[21:06:50] <mru> I guess that's to switch the compiler from whatever its default is
[21:07:01] <mru> iirc gcc on osx is -m32 by default
[21:07:08] <mru> linux is usually -m64 by default
[21:08:05] <DonDiego> yeah, but it seems weird to me
[21:08:14] <mru> tell that to steve jobs
[21:08:25] <DonDiego> oh, it's not just used on os x..
[21:08:44] <DonDiego> http://fate.multimedia.cx/index.php?build_record=205613
[21:08:47] <DonDiego> gcc on linux
[21:08:50] <mru> well, how did you expect to choose something other than the default?
[21:09:13] <DonDiego> why is there a need to deviate from the default i wonder
[21:09:14] <mru> that's doing a 32-bit build on a 64-bit machine
[21:09:43] <mru> it makes sense for 64-bit to be the default on a 64-bit machine
[21:09:54] <DonDiego> where do you see it's a 64 bit machine?
[21:09:59] <mru> I assume it is
[21:10:13] <pJok> os x is 32bit kernel  with 64bit userland afair
[21:10:15] <mru> and the /fate64 path suggests it is
[21:10:25] <DonDiego> let me doublecheck..
[21:10:42] <mru> pJok: that's not possible
[21:10:47] <astrange> it is possible
[21:10:51] <mru> wtf?
[21:10:52] <pJok> mru, of course it is
[21:10:55] <astrange> that's what it does
[21:11:06] <mru> how the fuck do you run a 64-bit userland on a 32-bit kernel?
[21:11:14] <pJok> ask apple
[21:11:21] <astrange> by caring really hard about driver compatibility
[21:11:24] <hyc> lol
[21:11:36] <mru> normal systems often do the opposite
[21:11:45] <mru> especially on ppc and mips
[21:11:53] <hyc> nope, not possible. unless you restrict the entire machine to less than 4GB of memory
[21:11:59] <mru> that's what I thought
[21:12:04] <pJok> can't see why 32bit kernel and 64bit userland shouldn't work
[21:12:14] <hyc> it could work but it would be stupid
[21:12:18] <pJok> hyc, virtual memory cures that anyways
[21:12:22] <astrange> it works with more than 4gb
[21:12:23] <hyc> no it doesn't
[21:12:29] <astrange> http://www.google.com/patents/about?id=DumnAAAAEBAJ
[21:12:29] <mru> how will a 32-bit kernel cope with userspace passing 64-bit pointers in syscalls?
[21:12:34] <hyc> exactly
[21:13:09] <astrange> it constantly remaps part of the kernel space
[21:13:16] <astrange> wastes a lot of tlb misses but it works
[21:13:23] <mru> eh, that won't help you
[21:13:28] <astrange> 64-bit kernel is much faster on (some) supported systems
[21:13:39] <mru> a 32-bit kernel _has no concept_ of 64-bit pointers
[21:13:39] <peloverde> It uses PAE, no?
[21:13:48] <mru> PAE is something different entirely
[21:13:58] * pJok has no idea how apple did it
[21:14:03] <pJok> and i find the idea stupid
[21:14:03] <mru> PAE is 40-bit (iirc) physical addresses
[21:14:08] <pJok> but it works, aparantly
[21:14:08] <mru> mapped into 32-bit virtual
[21:14:27] <hyc> PAE is only 36 bit
[21:14:35] <mru> right, it was tiny
[21:14:41] <hyc> any way you slice it, cannot handle 64 bit pointers
[21:14:54] <peloverde> PAE is 52-bits
[21:15:05] <mru> I doubt that
[21:15:18] <mru> I've never heard of _any_ machine with 52-bit physical
[21:15:32] <mru> they usually top out around 48
[21:15:35] <hyc> right, current x86s top out at 40 bits
[21:15:45] <peloverde> http://support.amd.com/us/Processor_TechDocs/24593.pdf
[21:15:53] <Dark_Shikari> mru: ppc
[21:16:06] <mru> I doubt that
[21:16:14] <mru> why would you have that many address bits?
[21:16:22] <Dark_Shikari> ppc32 has a 52-bit address space
[21:16:28] <Dark_Shikari> It's actually rather amusing
[21:16:34] <mru> that's crazy
[21:16:46] <pJok> wiki says PAE is UP TO 52bit
[21:16:49] <mru> which ppc32 btw?
[21:17:06] <Dark_Shikari> all, I think
[21:17:16] <mru> pJok: oh, maybe the register format can handle it
[21:17:23] <Dark_Shikari> it's a "virtual address space" technically
[21:17:26] <Dark_Shikari> but it acts like a physical one
[21:17:38] <hyc> peloverde: the AMD doc says up to 52 bits may be supported, current AMD64 arch supports 40.
[21:17:40] <mru> wtf does that mean?
[21:17:50] <mru> Dark_Shikari: ^^
[21:17:54] <pJok> "x86 processor hardware architecture is augmented with additional address lines used to select the additional memory, so physical address size is increased from 32 bits to 36 bits. This, theoretically, increases maximum physical memory size from 4 GB to 64 GB. The 32-bit size of the virtual address is not changed, so regular application software continues to use instructions with 32-bit addresses and (in a flat memory model) is limited to 
[21:18:03] <pJok> dunno how much of that got cut off
[21:18:08] <Dark_Shikari> mru: ok, if I recall correctly, here's how it works
[21:18:12] <mru> I know how x86 pae works
[21:18:18] <Dark_Shikari> the top 4 bits of each 32-bit address is a segment identifier
[21:18:21] <mru> wider physical than virtual, simple
[21:18:29] <Dark_Shikari> this maps to a list of 16 segments (like a mini page table)
[21:18:37] <Dark_Shikari> each segment maps to a list of pages for that segment
[21:18:41] <Dark_Shikari> the pages are in a 52-bit virtual address space
[21:19:00] <hyc> none of this matters. 64 bit userland uses 64 bit flat pointers.
[21:19:54] <DonDiego> --cc='ccache suncc' --extra-cflags=-Wa,-a32
[21:20:02] <DonDiego> what weird stuff is that?
[21:20:03] <peloverde> then limit each process to 4GB?
[21:20:07] <mru> someone wants to use ccache, normal stuff
[21:20:13] <mru> don't know about the -a32
[21:20:44] <pJok> "Mac OS X for Intel Macs supports PAE and the NX bit on all CPUs supported by Apple (from 10.4.4, the first Intel release, onwards). Mac Pro and Xserve systems can currently support 32 GB of RAM, even though the Mac OS X 10.5 Leopard kernel remains 32-bit. The Mac OS X 10.6 Snow Leopard kernel can optionally run in 64-bit on certain systems.[6]"
[21:21:22] <DonDiego> i meant the -Wa,-a32
[21:21:36] <hyc> so, 10.6 is a 64 bit kernel
[21:21:54] <hyc> and 10.5 was pure 32 bit
[21:22:11] <astrange> it's optionally 64 bit but not by default
[21:22:23] <mru> then 64-bit userland is optional too
[21:22:24] <astrange> and it's invisible to userland whether it is or not (excepting sysctl)
[21:22:55] <mru> they must have a _really_ contorted syscall interface if that's possible
[21:22:59] <hyc> it would be fake 64 bit then. 64 bit wide pointers that always contain only 32 bits
[21:23:46] <hyc> and they would still have to rearchitect when going to a native 64 bit kernel. yeah, makes no sense
[21:23:52] <astrange> i'm running it right now and it works completely normally
[21:24:00] <hyc> unless they always used 64 bits in the syscall interface
[21:24:03] <astrange> do you not believe that actual running systems work?
[21:24:06] <mru> I have yet to see _anything_ normal on a mac
[21:24:16] <hyc> sure they work, just not the way you seem to believe
[21:24:17] <astrange> and yes, the syscall interface is 64-bit on the user side
[21:24:22] <DonDiego> where do i see who maintains each fate box?
[21:24:33] <mru> there's a list on the wiki
[21:24:35] <astrange> i've been to the wwdc kernel session about this
[21:24:42] <siretart> greetings from Paris!
[21:25:01] <mru> siretart: enjoy the expensive beer
[21:25:13] <thresh> and lack of taxis
[21:25:19] <mru> that too
[21:25:23] <mru> crazy city
[21:25:36] <siretart> indeed, I can confirm both
[21:25:53] <mru> of course, we wouldn't make stuff up, would we?
[21:26:06] <siretart> heh
[21:27:36] <DonDiego> bah
[21:27:54] <DonDiego> i cannot match up fate runs with the machine descriptions on the wiki..
[21:27:56] <DonDiego> *sigh*
[21:28:54] <DonDiego> how can i tell which one is testing suncc?
[21:29:32] <pJok> http://www.appleinsider.com/articles/08/08/26/road_to_mac_os_x_10_6_snow_leopard_64_bits.html&page=2
[21:29:53] <pJok> there's something about tiger running 64bit apps with 32bit kernel
[21:30:05] <astrange> that's normal
[21:30:11] <astrange> snowleopard/10.6 is the only one that does new stuff
[21:30:27] <astrange> er, i read that backwards
[21:30:48] <pJok> http://images.appleinsider.com/road-to-sl-080826-3.gif
[21:32:23] <pJok> mru, thats where you have the 32bit kernel/64bit userland
[21:33:43] <hyc> ok. it's a 64-bit clean syscall interface
[21:33:49] <hyc> but a 32 bit kernel with PAE
[21:34:08] <hyc> that would explain one reason why their kernel was so slow
[21:34:30] <astrange> xnu is slow all by itself
[21:34:54] <astrange> partially because it has 4gb kernel/4gb userland on 32-bit so there's never any situation where it can do fast kernel<>userland copies
[21:35:18] <astrange> ...except with x86-64 kernel and userland
[21:36:18] <DonDiego> Build string:  'rm -rf /home/mik/src/fate/build && mkdir -p /home/mik/src/fate/build/tmp && cd /home/mik/src/fate/build && /home/mik/src/fate/source/configure --cc=gcc-4.4 --disable-stripping --disable-optimizations --extra-cflags='-O3 -fno-omit-frame-pointer' --target-exec='valgrind --leak-check=full --error-exitcode=1 --malloc-fill=0xff --suppressions=/home/mik/src/fate/fate.supp --log-file=/home/mik/src/fate/build/fate-valg
[21:36:29] <DonDiego> what weird config is that?
[21:37:05] <drv> is that the valgrind one?
[21:37:46] <DonDiego> that would explain it..
[21:37:51] <DonDiego> Yuvi: you around?
[21:39:06] <drv> http://lists.mplayerhq.hu/pipermail/fate/2010-March/000001.html is the FATE thread about valgrind
[21:39:32] <pJok> Still doesn't explain why flash is so slow under os x though...
[21:40:32] <hyc> flash is slow on any OS
[21:40:52] <astrange> they don't spend any time caring and the netscape plugin api was poorly adapted to os x's double buffered windows
[21:40:53] <hyc> it's just poorly written
[21:41:10] <astrange> supposedly they're working it out now, but iirc plugin drawing is still based on polling
[21:41:12] <Compn> its explained in mike's post on why flash is so slow
[21:41:27] <Compn> e.g. overlay crap on top of video
[21:41:40] <mru> I can tell you _exactly_ why flash is slow
[21:41:40] <Compn> not to mention that its crap...
[21:41:43] <pJok> Its certainly slower on my mac which is more powerful than my pa laptop
[21:41:45] <mru> IT'S CRAP
[21:41:49] <hyc> even without those issues flash would still be slow
[21:41:55] <DonDiego> Compn: that does *not* explain it
[21:41:56] <mru> the source code is mostly ifdefs
[21:41:58] <Compn> ehe
[21:41:58] <hyc> it's like trying to write a kernel in BASIC
[21:41:59] <pJok> Macbook*
[21:42:08] <Compn> can anyone explain why quicktime is so slow?
[21:42:09] <Compn> :P
[21:42:13] <mru> it's crap
[21:42:17] <hyc> lol
[21:42:32] <DonDiego> mplayer is 5x faster even with vo_x11, i.e. with color conversion
[21:42:33] * drv sends out to get a rubber stamp with "It's crap" on it
[21:42:48] <hyc> get extras, I need one ;)
[21:42:51] <pJok> At least you can single frame step in quicktime player...
[21:43:00] <mru> mplayer is pretty weird, but it's usually quite fast
[21:43:06] <mru> when it doesn't crash
[21:43:16] <drv> qt player takes about 20-30 seconds to start on windows, fairly pitiful
[21:43:47] <j-b> http://newteevee.com/2010/04/12/google-to-open-source-vp8-for-html5-video/ bye bye theora?
[21:44:17] <mru> "multiple sources" have been spouting that stuff for a long time
[21:44:31] <hyc> of course they just spent money on theora
[21:44:34] <mru> that doesn't look any more credible than the earlier ones
[21:44:43] <astrange> can we send someone to i/o to yell at them until they let someone else review the bitstream format?
[21:44:54] <pJok> With an older version of itunes, try uninstalling qt and make either work again...
[21:44:54] <DonDiego> i/o?
[21:45:01] <astrange> the google conference
[21:45:23] <DonDiego> what bitstream format are they reviewing?
[21:45:32] <astrange> the one in j-b's link
[21:46:13] <mru> I'll believe it when I see an official press release from google
[21:46:15] <mru> not sooner
[21:47:33] <peloverde> not to mention that that vp8 may very well not be the panacea they make it out to be
[21:47:43] <mru> of course it's not
[21:47:48] <peloverde> And Bilski v Kappos comes back soon
[21:47:50] <Yuvi> DonDiego: pong
[21:48:07] <DonDiego> Yuvi: ah, good you're around again..
[21:48:11] <DonDiego> Yuvi: seen my mail?
[21:48:33] <Yuvi> not yet, I'm still catching up
[21:48:40] <BBB> KotH: ping
[21:48:57] <DonDiego> Yuvi: you were away?
[21:49:15] <Yuvi> yeah, dealing with family stuff across the country
[21:49:20] <mru> how are we doing for gsoc btw?
[21:49:57] <CIA-81> ffmpeg: stefano * r22864 /trunk/libavcodec/eval.h: Remove stray empty line.
[21:49:57] <CIA-81> ffmpeg: stefano * r22865 /trunk/libavcodec/eval.h: Fix grammar: a expression -> an expression.
[21:50:55] <BBB> mru: 11 applications, 10 of which are non-spam
[21:50:56] <Yuvi> so I unfortunately haven't done anything with ogg/theora
[21:51:08] <Yuvi> chained ogg? I'll look at that
[21:51:08] <BBB> mru: awaiting qualification task results for them
[21:51:32] <BBB> mru: expect ~ 4-8 soc projects
[21:52:59] <DonDiego> Yuvi: there were some crashers that Dark_Shikari found with the fuzzer
[21:53:13] <DonDiego> do you remember if they could have been exploitable?
[21:53:33] <Yuvi> iirc just DoS / overreads
[21:53:55] <Yuvi> so probably not
[21:54:40] <DonDiego> ok
[21:54:51] <DonDiego> will you be around in the next few days?
[21:55:03] <Yuvi> yep, I'm back home now
[21:55:13] <DonDiego> i'll try to catch you on irc/email then, i'm terribly tired right now..
[21:56:59] <DonDiego> gnite
[22:06:09] <CIA-81> ffmpeg: stefano * r22866 /trunk/libavcodec/raw.c:
[22:06:09] <CIA-81> ffmpeg: Change ff_raw_pixelFormatTags RGB entries (RGB555, BGR555, RGB565,
[22:06:09] <CIA-81> ffmpeg: BGR565, RGB565) to make them specify the tags for the LE variants
[22:06:09] <CIA-81> ffmpeg: rather than for the native endian ones.
[22:06:09] <CIA-81> ffmpeg: Fix NUT compatibility.
[23:07:37] <BBB> Vitor1001: thanks for the comments
[23:16:38] <Vitor1001> I hope I didn't said anything meaningless
[23:25:44] <BBB> no, quite the contrary, especially the review of that denoise filter was useful, it's still dark-grey magic to me
[23:25:51] <BBB> but not completely black anymore, maybe
[23:36:05] <Kovensky> ohi Vitor1001
[23:36:18] <Vitor1001> Kovensky: Hi
[23:36:37] <Kovensky> does libavfi handle audio filtering already
[23:36:46] <Vitor1001> No
[23:36:54] <Kovensky> hmm
[23:36:58] <Vitor1001> There also much little code wrote during soc
[23:37:09] <Kovensky> any idea on what I could read to know how to make an audio filtering system? =p
[23:37:24] <Kovensky> gonna do one for x264 for gsoc
[23:37:34] <Kovensky> (if they approve me)
[23:37:49] <Vitor1001> x264?
[23:37:53] <Vitor1001> you mean vlc?
[23:38:02] <Kovensky> well, vlc is the org, but the project is for x264
[23:38:16] <mru> hardcore
[23:38:42] <j-b> no, vkc is not an org
[23:38:46] <Kovensky> it's to support x264's video filtering system and the future --device option
[23:38:47] <j-b> VideoLAN is
[23:39:06] <Kovensky> x264 randominput --device psp output.mp4 <-- file ready to put on a psp and play
[23:39:10] * Vitor1001 thinks x264 is trying to reinvent ffmpeg
[23:39:12] <Kovensky> well, -o output.mp4
[23:40:07] <Kovensky> perhaps
[23:40:11] <Vitor1001> Kovensky: I'd say if you are working in a audio filtering API, focus on the API side
[23:40:23] <Vitor1001> That's hard, and it should be done right
[23:40:27] <Kovensky> that's what I'm stuck at right now
[23:40:37] <Kovensky> I don't know how to handle the passing of packets between filters
[23:40:59] <Kovensky> since a filter will request packets from the previous one; and I don't know what unit should be an "audio frame" at the filter level
[23:41:15] <Vitor1001> I'd say you will need some ref-counted allocation
[23:41:24] <Kovensky> (and how to convert the filter-level audio frame to container-level frame on the demuxer / decoder / encoder / muxer)
[23:41:41] <Vitor1001> I'd say anything... There is no restriction you can put that will be uniform across filters
[23:42:33] <Kovensky> an idea I had was 1 frame = 1 sample, since I heard that's what avs uses
[23:42:38] <Vitor1001> I'd say a filtering framework would get some arbitrarily sized packet as input and output an arbitrarily sized (of a possibly different size) packet
[23:42:40] <Kovensky> but then I get stuck at the demuxing level thing
[23:42:52] <Vitor1001> 1 sample??
[23:43:03] <Vitor1001> You mean 2 bytes for signed 16-bit?
[23:43:13] <Kovensky> 4 bytes for 2ch s16le, etc
[23:43:21] <Vitor1001> Thats _way_ inefficient
[23:43:32] <Kovensky> a filter wouldn't request an individual frame, it'd request ranges
[23:44:28] <Vitor1001> what do you mean a range?
[23:44:42] <Vitor1001> More precisely, what would mean the start of the range?
[23:45:02] <Vitor1001> You mean it request a number of samples?
[23:45:29] <Kovensky> yes
[23:46:02] <Kovensky> encoder wants to encode a frame, requests (encoder's frame size) samples to previous filter, and it cascades down to the decoder
[23:46:53] <Vitor1001> Looks good
[23:47:08] <Kovensky> but then I get stuck at 1) how does the muxer make the request to the encoder, and 2) how does the decoder make the request to the demuxer
[23:47:14] <Vitor1001> but there should be a way to avoid duplicating some caching in each filter
[23:47:29] <Kovensky> I thought about having a cache filter between each one, but that might be too heavy weight
[23:48:08] <Vitor1001> You have to cache only after the filters that cannot output some arbitrary sizes
[23:48:45] <Vitor1001> Gluing it up to x264 is a different problem
[23:48:47] <Kovensky> also, I not always have control over the demuxing; since for example on x264's lavf demuxer, the video reader reads packets until it gets one it likes; so I'd have to make it a bastard audio demuxer that pushes packets to a queue as it finds them
[23:49:06] <Vitor1001> if the library is supposed to be self-contained, it should not dictate too much its design.
[23:49:40] <Kovensky> I think I can make it self-contained, at least that's what I'm doing for now (to simplify testing)
[23:49:48] <Vitor1001> And you should make a decision.
[23:49:59] <Kovensky> which decision
[23:50:05] <Vitor1001> Will you support "delay=1h" filter?
[23:50:18] <Vitor1001> (which would delay the audio 1 hour)?
[23:50:44] <Kovensky> that's a weird filter
[23:50:59] <Vitor1001> I know.
[23:51:00] <Kovensky> it could work by rewriting requested timestamps and returning silence when needed
[23:51:19] <Vitor1001> Yes, but it will need either:
[23:51:27] <Vitor1001> 1- Buffer one hour of audio
[23:51:40] <Vitor1001> 2- Seek back everytime it need a audio frame
[23:52:03] <Vitor1001> I would suggest you not try to do this kind of thing in a first audio filtering framework
[23:52:11] <Kovensky> indeed...
[23:52:34] <Kovensky> I know for sure I can't seek back because input from libavformat is not guaranteed to be a regular file
[23:53:04] <Vitor1001> Buffering an hour of raw audio to RAM is also not a good idea
[23:53:24] <mru> ram is cheap :-)
[23:53:35] <Kovensky> when I know that a file is a regular file (like when the ffms2 demuxer is used on x264), I don't bother dealing with ffms; I just make the audio-specific lavf demuxer open the file again
[23:53:42] * Vitor1001 invites mru to do the same with video ;)
[23:54:03] <mru> I'm not _that_ rich...
[23:54:05] <Kovensky> then it doesn't need seeking or buffering; but I guess that counts as a seek for the HDD =p
[23:54:34] <Kovensky> well, be back soon; dinner
[23:55:59] <Vitor1001> Kovensky: My point is that in a first time, it would be better to suppose your filtering framework can ignore these problematic cases...
[23:56:56] <Vitor1001> Am I the only one bothered about the effort duplication between ffmpeg and x264?
[23:58:24] <SmkMnstr> what about about openmax
[23:58:33] <mru> lol
[23:58:45] <mru> openmax is _multiplication_ of effort