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

[irc at mansr.com]

[01:31:36] <EricAhn_> who know the url of ffmpeg QA?
[01:32:01] <BBB> http://fate.ffmpeg.org/ ?
[01:32:58] <EricAhn_> BBB : it's just result of compile.
[01:33:08] <BBB> what is?
[01:33:33] <BBB> that webpage runs our complete testsuite (which tests most/all decoders and a whole bunch of encoders) on a variety of systems
[01:33:34] <EricAhn_> BBB : are there any static analysis, and Quality of assurence?
[01:34:02] <BBB> quality assurance is what? that's a business term
[01:34:21] <ohsix> wat
[01:34:58] <EricAhn_> clang static analyzer,
[01:35:06] <EricAhn_> sort of coverity, zzuf
[01:35:35] <EricAhn_> http://clang.llvm.org/StaticAnalysis.html
[01:35:44] <EricAhn_> http://scan.coverity.com
[01:35:52] <EricAhn_> http://caca.zoy.org/wiki/zzuf
[01:35:52] <BBB> oh, that - people sometimes run it on ffmpeg
[01:35:58] <BBB> but it's not done on a regular basis
[01:36:08] <BBB> zzuf is done when committing new stuff to the tree
[01:36:13] <EricAhn_> I think that have some difficult of sample stream test.
[01:37:08] <BBB> all you need to do using zzuf is correct error handling,t he output isn't expected to be playable so we don't add it to the testsuite
[01:37:59] <BBB> if you have ideas on how to automate that, it'd be very welcome, I guess
[01:38:02] <ohsix> ya but correct isn't provable :D
[01:38:31] <BBB> I think that's the major problem with automating it
[01:38:42] <EricAhn_> I don't know using zzuf, It's great thing, I want to find some more easily automat tools and method.
[01:38:49] <BBB> it's unclear what to expect (except that it doesn't crash)
[01:39:25] <ohsix> and sometimes stuff happens without a crash that would be of concern
[01:40:00] <BBB> right
[04:39:37] <Dark_Shikari> mru: comments on ARM Cortex A15?
[05:18:25] <_av500_> Dark_Shikari: u got the data sheet?
[10:51:16] <cartman> Processor	: ARMv7 Processor rev 2 (v7l)
[10:51:18] <cartman> BogoMIPS	: 162.54
[10:51:23] <cartman> is this slow or what?
[10:52:03] <mru> normally you get a bogomips number about the same as the cpu clock
[10:52:07] <mru> on arm
[10:52:20] <Dark_Shikari> mru: got my question earlier?  thoughts on the cortex a15?
[10:52:27] <mru> Dark_Shikari: no info available
[10:52:35] <Dark_Shikari> any thoughts even given the public info?
[10:52:37] <mru> cartman: what system is that?
[10:52:38] <cartman> mru: is this Cortex-A8?
[10:52:38] <Dark_Shikari> that is, 16 cores, 2.5ghz?
[10:52:42] <mru> Dark_Shikari: there is no public info
[10:52:46] <mru> only marketing drivel
[10:52:49] <cartman> mru: some Android tablet out of EFA
[10:52:57] <Dark_Shikari> mru: you don't trust ARM's own specs on it?
[10:53:00] <twnqx> Dark_Shikari: 2012, the world will by finished when it's out anyway
[10:53:06] <mru> Dark_Shikari: there are no specs available
[10:53:08] <Dark_Shikari> Or do you think this is another case of ARM's marketing not matching the reality of an actual produced chip?
[10:53:17] <Dark_Shikari> i.e. ARM saying "the chip will be 2ghz" and then it's 1ghz.
[10:53:24] <mru> it's a multi-core armv7 with 40-bit physcal addr and virtualisation stuff
[10:53:29] <mru> that's all there is so far
[10:53:45] <av500> Dark_Shikari: the speed will be whatever arms licensees make out of it
[10:54:15] <cartman> mru: anyway to find out if this is a Cortex-A8 ?
[10:54:27] <mru> cartman: the rest of cpuinfo tells you
[10:54:30] <mru> pastebin it
[10:54:30] <Dark_Shikari> mru: well, from first appearances it appears to be an attempt at a server chip
[10:54:34] <Dark_Shikari> which may actually be rather interesting
[10:54:34] <cartman> mru: one sec.
[10:54:43] <av500> Dark_Shikari: and if it is intended for servers, power could be traded for speed more easily
[10:54:48] <mru> Dark_Shikari: it has things that would be useful for servers, yes
[10:54:54] <Dark_Shikari> mru: well, the point being, too high power for mobiles
[10:54:57] <cartman> mru: http://pastebin.com/wcnUUdA7
[10:54:57] <Dark_Shikari> but much more efficient than x86
[10:55:08] <av500> mahimahi!
[10:55:24] <cartman> oh yeah
[10:55:36] <mru> wtf is that chip?
[10:55:39] <cartman> :D
[10:55:40] <cartman> lol
[10:55:51] <cartman> not Cortex-A8 then
[10:56:02] <mru> pastebin first few lines of dmesg
[10:56:36] <mru> hang on, that's a qualcomm core
[10:56:55] <merbzt> cellphone then
[10:57:06] <wbs> cartman: looks like the same as in my nexus one at least
[10:57:16] <cartman> wbs: oooooh
[10:57:18] <cartman> coool
[10:57:23] <cartman> merbzt: tablet
[10:57:26] <cartman> a 7'' tablet
[10:57:30] <cartman> looks like crap
[10:57:38] <mru> the low bogomips could be a result of the clock being set low when check was done
[10:57:55] <av500> mru: its a mahimahi
[10:58:02] <mru> means nothing to me
[10:58:18] <av500> http://www.linuxhq.com/kernel/v2.6/35-rc1/arch/arm/mach-msm/board-mahimahi.c
[10:58:20] <av500> but to google
[10:58:24] <av500> and its a tasty fish
[10:58:31] <mru> yes, the fish I'm aware of
[10:58:33] <av500> I ate one in mountain view :)
[10:58:34] <cartman> nice
[10:58:48] <mru> a whole one?  aren't they rather big?
[10:58:50] <cartman> this shit might run 2.2 too :P
[10:59:02] <av500> mru: it was fish on a plate
[10:59:20] <av500> i did not care if there was more of it :)
[10:59:48] <peloverde> Red Hat admits Theora and VP8 are patented? http://spot.livejournal.com/312320.html?thread=1472256#t1472256
[11:00:07] <kshishkov> av500: next time ask for grilled xiphophorus and eat it in Monty's presence
[11:00:21] <av500> peloverde: err?
[11:00:30] <av500> ah, i see
[11:01:09] <jannau> lol: "So then why hasn't anybody written a wrapper for ffmpeg programs to use GStreamer instead?"
[11:01:34] <jannau> double funny if gst uses ffmpeg
[11:01:40] <mru> of course it does
[11:01:45] <Dark_Shikari> jannau: you can make it recursive
[11:01:47] <Dark_Shikari> ffmpeg calls gst
[11:01:48] <Dark_Shikari> gst calls ffmpeg
[11:01:50] <mru> gst couldn't exist without ffmpeg
[11:01:51] <Dark_Shikari> mutual recursion.
[11:02:03] <jannau> endless wrapper loop
[11:02:03] <av500> wrappers all the way down
[11:02:22] <jannau> s/endless/infinite/
[11:02:25] <kshishkov> av500: sounds like some product descriptions
[11:02:45] <Dark_Shikari> BBB___: so, how long will it take for the improved performance numbers to convince michael that inline asm + gcc sucks?
[11:02:55] <av500> kshishkov: of course it can be refactored to have a wrapper factory pattern
[11:03:14] <mru> Dark_Shikari: have you heard about ostriches and sand?
[11:03:18] <kshishkov> Dark_Shikari: until you convert all inline asm to standalone ;)
[11:03:38] <Dark_Shikari> kshishkov: no, he will still complain then
[11:03:50] <av500> mru: sand stick their head into ostriches?
[11:03:53] <kshishkov> av500: I heard there are special languages designed for wrappers - like Java
[11:04:09] <lu_zero> brr
[11:04:20] <av500> java is nice, it just had a bad start :)
[11:04:21] <lu_zero> monday...
[11:04:36] <kshishkov> av500: at least it'
[11:04:44] <kshishkov> s finally on embedded platform
[11:04:52] <av500> wait until they rename it to "oracle database script"
[11:05:02] <BBB___> Dark_Shikari: forever, of course
[11:05:08] <BBB___> Dark_Shikari: shouldn't you sleep? it's 4am there
[11:05:26] <Dark_Shikari> I slept for about 5 hours earlier
[11:05:30] <kshishkov> av500: that's PL/SQL
[11:05:50] <BBB___> weird timing...
[11:05:54] * BBB___ goes have breakfat
[11:06:02] * av500 goes for lunch
[11:06:19] <mru> lunch, good plan
[11:06:32] <lu_zero> interesting plan
[11:06:58] * kshishkov would like to order köttbullar med potatismos ock lingonsylt again
[11:07:27] <mru> kshishkov sounds like a swedish school kid
[11:07:34] <cartman> this is a ragter slow tablet
[11:07:41] <cartman> rather*
[11:07:49] <kshishkov> mru: not that I mind.
[11:08:14] <andoma> kshishkov: IKEA should be able to provide that, worldwide, no?
[11:08:24] <kshishkov> cartman: well, Chinese are known to produce a lot of oversized PDAs and market them as something else
[11:08:36] <cartman> kshishkov: true
[11:09:00] <kshishkov> andoma: it's still not worldwide and I've never been to IKEA. Even in Skärholmen
[11:09:42] <jannau> andoma: they do at least in germany
[11:10:36] <jannau> but no ikea in karlsruhe
[11:11:25] * kshishkov would prefer ICA or Hemköp with corresponding working hours
[11:12:04] * superdump would prefer if systembolaget were open the same hours as supermarkets
[11:12:26] * kshishkov likes systembolaget idea as it's implemented now
[11:13:34] <superdump> there are still drunkards
[11:13:39] <superdump> they just have to plan ahead
[11:14:22] <kshishkov> well, you should benefit from educational trip to East Europe
[11:48:38] <vipw> there's still folkol for the very patient
[11:50:17] <spaam> folköl ;S  i dont like that :)
[11:53:38] <Tjoppen> don't diss the folle
[12:03:25] * kshishkov lived in Germany long enough to find out what they call "öl" here
[12:17:45] <superdump> folkcider is sometimes ok if you just want something kind of resfreshing
[12:18:07] <superdump> but if your goal is mild drunkenness, it's fail
[12:18:32] <kshishkov> if your goal is drunkedness, *you* fail
[12:19:15] <mru> 5% is about right for something you intend to drink in quantity
[12:19:56] <mru> kshishkov: there's no harm in a little mild drunkenness from time to time
[12:20:06] <superdump> yup
[12:20:11] <kshishkov> mru: actually there is
[12:20:26] * mru usually caps it at 5 pints or so
[12:20:52] <kshishkov> had I studied biology better, I'd describe what it does to your organism
[12:20:55] <superdump> pint? what is this archaic measure? :)
[12:21:10] <mru> kshishkov: I know exactly what it does
[12:21:12] <kshishkov> superdump: it's imperial, you Norwegian
[12:21:38] <mru> and I know alcohol is toxic in large amounts
[12:21:59] * kshishkov wonders if Swedes really had "kaffeekoppa" unit of volume and if yes then what they were drinking?
[12:22:10] <kshishkov> mru: everything is
[12:22:26] <mru> kaffekopp is a fairly standard measure, yes
[12:22:34] <kshishkov> mru: though there's saying "Alcohol in small doses is harmless in any amounts"
[12:23:17] * kshishkov also found it surprising that järnvag distance is measured in mil
[12:23:26] <mru> everything is in sweden
[12:23:32] <mru> road distances too
[12:23:37] <mru> unofficially
[12:23:45] <mru> signs are in km
[12:23:58] <merbzt> but it is atleast sane
[12:24:09] <mru> yes, 10km is a sane number
[12:24:20] <mru> also quite practical for long distances
[12:24:50] * kshishkov looked at "http://www.botniabanan.se/templates/BotniaLopsedel.aspx?id=1961", section "Fakta"
[12:34:52] * cartman hates the German visa stuff
[12:34:57] <cartman> holland was easier
[12:35:05] <av500> its for your own good
[12:35:19] <cartman> yeah I should attent Nokia conferences
[12:35:21] <cartman> not*
[12:35:30] <av500> see
[12:35:43] <cartman> they charge me double because my wife is coming too
[12:35:46] <cartman> burglars
[12:35:59] <mru> get fake passports instead
[12:36:04] <mru> much simpler
[12:36:08] <cartman> visa you mean :P
[12:36:16] <av500> cartman: no discount for many wives?
[12:36:28] <av500> bring3, pay2
[12:36:29] <mru> no, fake passports from a country that doesn't need visa
[12:36:32] <cartman> av500: yeah none, please complain to your government
[12:36:40] <cartman> mru: bah
[12:37:03] <av500> cartman: i dont complain, your visa money suits me nicely
[12:37:17] <cartman> av500: true
[12:37:20] <cartman> you bastard
[12:37:48] <BBB> Dark_Shikari: so I use ADD and SUB if I fsck around with esp inside asm... is there something similar for CALL?
[12:38:02] <kshishkov> cartman: he may held some historical grudges against you
[12:38:14] <Dark_Shikari> BBB: why would you need that?
[12:38:22] <BBB> I'm doing something very evil
[12:38:27] <av500> kshishkov: true, somebody had to keep the turks out
[12:38:34] <Dark_Shikari> explain
[12:38:35] <cartman> kshishkov: :(
[12:38:44] * cartman is innocent
[12:38:56] <BBB> r0 is uint8_t **dst, I want to keep a backup of that, so on x86-64, that is r10, and on x86-32, it is r0m
[12:39:02] <mru> cartman: what have you done to be innocent of?
[12:39:06] <BBB> but I call an internal function which has to access this also
[12:39:10] <kshishkov> cartman: unlike Ukraine - Turks plundered and pillaged Ukraine, Ukrainian cossaks (do you recognize the word?) plundered and pillaged Turkey, all fair and square
[12:39:13] <BBB> on x86-64 this works, r10 isn't touched
[12:39:22] <Dark_Shikari> BBB: %define it
[12:39:23] <BBB> on x86-32 this fails because r0m isn't valid anymore after the call
[12:39:30] <cartman> mru: wasn't me
[12:39:35] <cartman> kshishkov: cossak?
[12:39:41] <kshishkov> cartman: yes
[12:39:51] <cartman> didn't recognize the word :/
[12:39:55] <BBB> Dark_Shikari: can't I manually subtract/add from the whatever-stack-counter-is around the call?
[12:40:00] <BBB> or is that what you mean?
[12:40:04] <Dark_Shikari> no...
[12:40:12] <Dark_Shikari> just keep track of the effect the call has on the stack pointer
[12:40:12] <kshishkov> cartman: and properly it should say to mru "I ain't did nuthin', guv"
[12:40:13] <Dark_Shikari> i.e. "4"
[12:40:20] <cartman> I am not here to conquer Munich :P
[12:40:27] <BBB> and then don't use r0m?
[12:40:30] <Dark_Shikari> you could also use r1m and put a comment about how gigantic a hack is
[12:40:33] <Dark_Shikari> *a hack that is
[12:40:35] <BBB> hahaha :)
[12:40:36] <kshishkov> cartman: well, it's said to come from Turk word for "robber" or "bandit"
[12:40:39] <thresh> cossacks or kazaks
[12:40:39] <BBB> I might just do that :-p
[12:40:43] * BBB likes the idea
[12:40:54] <cartman> thresh: kazak ah
[12:41:05] <cartman> treats us right
[12:41:36] <thresh> pedowikia says 'adventurer' or 'free man' in Turkish
[12:41:53] <kshishkov> lol, I wouldn't believe it
[12:42:07] <kshishkov> (except you read tr.wikipedia.org)
[12:42:12] <BBB> Dark_Shikari: is the effect of call on the stack-pointer system-dependent?
[12:42:20] <BBB> Dark_Shikari: it seems like it's 8 here, not 4
[12:42:32] <BBB> (x86-32 binary really)
[12:42:58] <Dark_Shikari> call pushes the instruction pointer onto the stack.
[12:43:04] <Dark_Shikari> This is sizeof(void*)
[12:43:07] <BBB> ok
[12:43:13] <BBB> I gotta figure out what I do wrong then
[12:43:14] <BBB> brb
[12:44:03] <mru> he's doing it wrong
[12:44:12] <mru> BBB does not know *it*
[12:44:24] <av500> i bet he is holding it wrong
[12:44:30] <Dark_Shikari> lol
[12:44:48] <mru> he's an apple fanboy, we know that much
[12:52:11] <kshishkov> well, x86 guys give us speedups there but it's mostly people who use different CPUs that RE codecs
[12:57:27] <av500> kshishkov: not much use to speed up gdium to decode 1080 in 10spf instead of 12?
[12:58:25] <Dark_Shikari> http://www.telegraph.co.uk/news/uknews/crime/7994298/Car-thief-fills-diesel-Audi-full-of-petrol.html
[12:59:44] <av500> thieves these days...
[12:59:49] <kshishkov> av500: yes, though no point there - too small display for that. But MPEG-4 ASP played almost fine
[13:26:54] <CIA-63> ffmpeg: siretart * r25113 /trunk/doc/ffmpeg-doc.texi: fix x11grab example in e.g. the manpage so that they actually work
[13:30:36] <BBB> Dark_Shikari: r1m works, thanks for the help
[15:04:32] <CIA-63> libswscale: ramiro * r32221 /trunk/libswscale/ (rgb2rgb.c rgb2rgb_template.c): swscale: avoid reading prior to the source buffer in planar2x() MMX2
[15:04:32] <CIA-63> libswscale: ramiro * r32222 /trunk/libswscale/rgb2rgb_template.c: swscale: indentation and emtpy line cosmetics
[15:49:31] <jannau> lol http://www.engadget.com/2010/09/13/boxee-box-ditches-nvidias-tegra-2-for-intel-ce4100-pre-orders/
[15:49:38] <av500> lol
[15:50:01] <jannau> high profile h264 playback was the issue
[15:50:17] <av500> orly :)
[15:50:52] <av500> jannau: finally I see it in writing :)
[15:52:27] <jannau> av500: mru already wrote it months ago
[15:53:25] <jannau> and this is still not a statement from nvidia
[15:53:41] <av500> jannau: Iknow
[15:53:44] <av500> but its good enough
[15:54:21] <kshishkov> av500: wan't Tegra crippled by design anyway?
[15:54:27] <av500> no
[15:54:31] <av500> well, a bit
[15:54:34] <jannau> no neon
[15:54:37] <mru> designed by cripples?
[15:54:48] <av500> having no neon means that there was no way to workaround the hd issue a bit in SW
[15:56:24] <kshishkov> mru: there was an ad long time ago for products made by blinds with slogan "Eyes can't see but hands remeber"
[15:57:08] <kshishkov> could be designed that way
[16:06:24] <lu_zero> maybe nvidia will provide a softneon through opencl
[16:06:29] * lu_zero runs away
[16:06:49] <mru> yeah right
[16:54:29] <thechistoso> hello -- not sure if this is the correct place or not -- but when using dxva2api.h for windows hardware accelerated decoding, you typically need to define COBJMACROS when using COM macros such as IDirectXVideoDecoder_Release. when compiling against the latest mingw-w64, for example, it fails b/c it cannot find the COM macros.
[16:56:01] <kierank> maybe sending a mail to fenrir or the mailing list might be better
[16:56:05] <thechistoso> i don't know where the fix lies, since it seems like it would be an autotools (configure) thing. adding CFLAGS="-DCOBJMACROS" gets me by for now, but it should be fixed.
[16:56:48] <thechistoso> kierank: ok -- i was hoping it'd be a quick fix :)
[16:57:46] <kierank> I don't think there's anybody particularly knowledgable about dxva on right now
[16:58:22] <thechistoso> in the future - does this belong on #ffmpeg or #ffmpeg-devel?
[17:00:47] <BBB> the function that breaks mpegvideo encoding on win64 is sse16_sse2... another yasm-convert-to-be, it seems
[17:02:34] <mru> is that the only one?
[17:03:11] <BBB> seems so
[17:03:20] <BBB> vsynth1-error succeeds with that commented out
[17:03:25] <BBB> let me run all of fate just to make sure
[17:03:46] <mru> that's a motion estimation function
[17:04:39] <mru> qtrle doesn't use that
[17:04:55] <BBB> I'm running full fate
[17:04:59] <BBB> if there's more, I'll fix more
[17:05:02] <BBB> one issue at a time ;)
[17:05:09] <mru> of course
[17:05:29] <BBB> vsynth1-mpeg2 also still fails
[17:05:33] <BBB> ok, there's apparently more to do
[17:09:09] <pJok> i wonder if ffmpeg compiles under this...: http://compcert.inria.fr/
[17:28:22] <mru> pJok: and they seriously believe that tool to be bug-free?
[17:29:00] <mru> and then there are hardware bugs
[17:29:57] <mru> "unreasonable forms of switch (e.g. Duff's device)"
[17:30:11] <mru> I think it's they who are unreasonable
[17:31:36] <mru> "performance ... often close to that of gcc (version 3)"
[17:31:54] <cartman> mru: talking about? Sorry for interrupting
[17:31:54] <mru> "on some classic computational kernels"
[17:32:11] <mru> http://compcert.inria.fr/
[17:32:33] <mru> i.e. tiny loops compilers writers have spent 3 decades tuning for
[17:32:57] <cartman> checked compilers
[17:32:58] <cartman> oh yeah
[17:33:10] <cartman> required for any mission critical stuff
[17:33:36] <mru> you're just pushing the burden one step down
[17:33:40] <mru> there are _always_ bugs
[17:33:51] <cartman> you need to document ways to recover from them :)
[17:34:00] <cartman> s/document/code
[17:34:22] <mru> there are bugs everywhere
[17:34:27] <mru> even in the recovery code
[17:34:39] <mru> there are also bugs in the _specification_
[17:35:00] <mru> which means the program might be doing exactly what the spec says, yet still be doing the wrong thing
[17:35:18] <cartman> hopefully you won't kill anyone ;)
[17:38:16] <cartman> I hate when people write HTML5 is the future in their blogs
[17:38:36] <kierank> so do i
[17:38:46] <kierank> html5 is the panacea to EVERY web problem
[17:38:59] <cartman> yeah, unfinished spec, low quality implementations
[17:39:11] <mru> it's the next evolution of html, that's all
[17:39:14] <kierank> at least flash is consistent
[17:39:35] <cartman> yeah it always eats 100% CPU
[17:39:38] <cartman> ;)
[17:39:41] <kierank> browsers implement html5 in differing ways. hmmmmmm where have we seen that before
[17:39:44] <kierank> cartman: html5 is worse
[17:39:53] <cartman> kierank: yup :>
[17:40:01] <cartman> at least Flash lets you view pr0n
[17:40:05] <cartman> no java crapplets
[17:40:32] <mru> you're missing the fundamental issue here
[17:41:03] <cartman> which is?
[17:41:43] <mru> not flash itself
[17:41:44] <mru> the real problem is the stupid shit people do with it
[17:41:51] <mru> stupid shit will be just as annoying if done in html5
[17:41:51] <cartman> true :)
[17:41:57] <mru> or any other buzztech
[17:42:14] <kierank> except in html5 it will end up using more cpu
[17:42:14] <mru> flash _also_ happens to be an utterly poor implementation
[17:42:16] <cartman> HTML5 still can't reliable show you any vide
[17:42:18] <cartman> +o
[17:42:31] <kierank> mru: poor but consistent
[17:42:46] <mru> consistently poor
[17:47:07] <Compn> so uh
[17:47:46] <Compn> why did everyone feel the need to use flash video transitions instead of just having plain video player and html transitions?
[17:48:07] <Compn> maybe fullscreen mode
[17:48:25] <pJok> mru, i wouldn't expect any software to be bug free, not even a simple hello world
[17:48:59] <mru> btw, isn't proving anything about a program related to solving the halting problem?
[17:50:39] <kshishkov> in a holistic way yes
[17:51:22] <_av500_> mru: ariane5 experienced a severe halting
[17:51:30] <_av500_> as did the mars probe
[17:51:50] <mru> yes, but brokie wasn't onboard either
[17:51:58] <pJok> wasn't the beagle lost due to inch/cm problems?
[17:52:11] <_av500_> yep
[17:52:13] <mru> pJok: buggy spec
[17:52:28] <mru> no verification of sw could have spotted that
[17:52:47] <_av500_> the live testing did
[17:52:59] <kierank> mru: are you going to write a troll blog post about the tegra 2?
[17:53:12] <mru> unless it included a full physics simulator and was able to conclude the forces in the impact would be too strong
[17:53:13] <pJok> mru, of course not
[17:53:40] <pJok> mru, no static checking can verify that your specs are wrong
[17:54:04] <mru> no automated procedure at all can do that
[17:54:56] <mru> anyway, let's build this thing and see what it does to ffmpeg
[17:55:11] <pJok> or what ffmpeg does to it
[17:55:18] <mru> more likely
[17:55:22] <_av500_> mru: ever saw a piece of sw run screaming from your hdd?
[17:56:01] <mru> is that what those strange noises are?
[17:56:15] <_av500_> thats the low flying disk head
[17:57:18] <pJok> mru, going to put it on fate if it actually compiles? ;)
[17:57:23] <mru> why not
[17:58:02] <pJok> would at least be interesting
[17:58:20] <pJok> to have yet another compiler squirm at every ffmpeg revision
[18:10:39] <peloverde> anyone understand GCC's new "ifunc" attribute?
[18:11:22] <_av500_> iFunc?
[18:12:07] <mru> new since when?
[18:12:09] <mru> 4.5?
[18:12:24] <peloverde> yes 4.5
[18:14:11] <peloverde> The example on nick clifton's blog doesn't seem useful enough to justify breaking compatibility with everything that isn't GCC unless I'm misunderstanding it http://nickclifton.livejournal.com/6612.html
[18:15:53] <mru> looks like a per-function runtime override
[18:16:24] <mru> I guess the idea is you'd check for mmx or whatever and select an optimised function if it's available
[18:16:44] <mru> without needing function pointers everywhere
[18:16:48] <cartman> not a bad idea
[18:17:08] <peloverde> but in his example why is that "resolve_memcpy" function any more usegul than just putting the check in "memcpy"
[18:17:41] <mru> you don't want to do the check on every call
[18:17:54] <mru> just like we have dsputil_init()
[18:17:56] <peloverde> so it saves the result between calls?
[18:18:11] <mru> it is called by the dynamic loader during symbol resolution
[18:18:19] <peloverde> ok
[18:18:41] <mru> not a bad idea, but the implementation looks dodgy
[18:18:48] <peloverde> that makes more sense
[18:18:51] <mru> it could all be handled in the linker
[18:19:14] <mru> without any need for special attributes
[18:19:46] <mru> or at most a special attribute on the resolver
[18:20:06] <mru> something like __attribute__((resolver("symbol")))
[18:20:26] <mru> when looking up a symbol, the linker could first check if there is a resolver for it and call that
[18:20:37] <mru> and if not, proceed as usual
[18:20:46] <peloverde> "-Wdouble-promotion" also looks useful, way easier than my approach of grepping objdump output for cvtss2sd
[18:20:55] <mru> hehe
[18:21:38] <cartman> HTML5 is indeed useful: https://bugs.webkit.org/show_bug.cgi?id=45645
[18:21:39] <cartman> lol
[19:12:39] <_av500_> vp6 has neon love?
[19:14:19] <j0sh> a few functions iirc
[19:21:07] <mru> yes, some
[19:25:41] <pJok> mru, how's the compiler coming on?
[19:26:06] <mru> building the prerequisites
[19:26:15] <mru> takes time on the old g4
[19:26:24] <pJok> ah yes, it was ppc only
[19:35:20] <bcoudurier> hi guys
[19:35:46] <mru> hi script
[19:40:56] <bcoudurier> it's me today
[19:42:41] <_av500_> prove it
[19:44:32] <BBB> haha that reminds me of that scene with the mexicans in family guy
[19:45:13] <Dark_Shikari> that's like "the scene with the flashback"
[19:47:19] <BBB> bleh can't find a youtube movie
[21:05:26] <jankowiak> Hi
[21:05:35] <jankowiak> I've been working on a simple player based on ffplay, I can stream directly from mp3, ogg files as well as from several internet radios
[21:06:00] <jankowiak> the only thing I've been having a problem with when using mms:// or mmst://
[21:06:44] <jankowiak> how do I add/build this in?
[21:07:21] <jankowiak> when I try an mms stream I get a no such file or directory error
[21:07:42] <jankowiak> any suggestions/tips would be greatly appreciated
[21:10:09] <Compn> --enable-network
[21:10:11] <Compn> or something
[21:10:14] <Compn> to that effect
[21:10:25] <mru> should be on by default
[21:10:26] <Compn> when compiling
[21:13:42] <jankowiak> according to my config.h it is on...
[21:17:52] <merbanan> jankowiak: try with mmsh instead of mms, it might work better
[21:19:26] <jankowiak> I still get the same error... it also happens with mmsu (which I don't think is actually implemented, or at least not completely)
[21:20:33] <merbanan> jankowiak: file a roundup issue so we can track it when it is implemented
[21:21:05] <jankowiak> If I can't get this to work, I can get a stream to connect and read using libmms, how would I send this data to ffmpeg?
[22:04:24] <CIA-63> ffmpeg: cehoyos * r25114 /trunk/libavcodec/utils.c: Test lowres before codec init.
[22:09:42] <CIA-63> ffmpeg: cehoyos * r25115 /trunk/ (8 files in 4 dirs):
[22:09:43] <CIA-63> ffmpeg: Add R10k decoder.
[22:09:43] <CIA-63> ffmpeg: Original patch by Zhou Zongyi, zhouzy A os pku edu cn, resubmitted by
[22:09:43] <CIA-63> ffmpeg: James Darnley, james.darnley gmail, changes by me.
[22:10:25] <CIA-63> ffmpeg: cehoyos * r25116 /trunk/libavcodec/r210dec.c: Reindent after r25115.
[22:14:57] <BBB> mru: you were right
[22:15:14] <mru> about what?
[22:15:19] <BBB> mru: hadamard_diff{,16}_ss{e2,se3} all are bad also
[22:15:25] <BBB> that it wasn't the only one ;)
[22:15:30] <mru> oh, that
[22:15:35] <BBB> with these 4 and sse16_sse2 commented out, win64 passes fate
[22:15:57] <BBB> that took me the whole day :-p crappy slow win64 remote connection
[22:16:06] <BBB> oh and fate being slow on win64
[22:16:22] <Dark_Shikari> You can import x264's SATDs into ffmpeg if you want
[22:16:26] <Dark_Shikari> they are easily 2-3x faster.
[22:16:29] <Dark_Shikari> They will also always be GPL.
[22:16:36] <mru> a full fate run takes something like 20s on my machine
[22:18:31] <BBB> Dark_Shikari: you can do that yourself, but the functions are still broken ;)
[22:18:57] <BBB> I cant fix it for GPL-zealots only :-p
[22:19:10] <jannau> mru: on windows the fork overhead is probably already two orders of magnitude higher
[22:19:12] <Dark_Shikari> s/GPL-zealots/everyone except Cisco/
[22:19:32] <Dark_Shikari> or <insert-companies-who-link-lgpl-to-proprietary-stuff-here>
[22:19:32] <mru> jannau: how do they manage to make it suck like that?
[22:19:38] <Dark_Shikari> but yes.
[22:19:45] <Dark_Shikari> mru: they don't have copy-on-write
[22:19:48] <Dark_Shikari> because windows doesn't have fork
[22:19:51] <Dark_Shikari> so logically there's no reason to have it
[22:20:05] <mru> start with one bad decision
[22:20:06] <Dark_Shikari> windows uses a spawn_process paradigm instead of fork/exec
[22:20:16] <Dark_Shikari> honestly, I don't really think fork/exec is that great a design.
[22:20:18] <mru> then use it to justify a host of other bad ideas
[22:20:40] <mru> how would you do fork _without_ exec on windows?
[22:20:43] <lu_zero> hi
[22:20:47] <Dark_Shikari> I think the Windows approach (which is also used by some other systems, including posix ones) is equally justifiably crappy.
[22:20:56] <Dark_Shikari> mru: the point is that in reality you almost never fork, you fork and then exec.
[22:21:00] <Dark_Shikari> aka "spawn new process"
[22:21:10] <Dark_Shikari> the unix paradigm is a hack.  it works, but it's hacky.
[22:21:16] <Dark_Shikari> Which really is the point of unix
[22:21:18] <Dark_Shikari> "worse is better"
[22:22:23] <Dark_Shikari> Though oddly enough, years later, they added a posix command to spawn a new process.
[22:22:34] <mru> there is also posix_spawn()
[22:22:36] <Dark_Shikari> The reason was because fork/exec is very very difficult to synchronize if the exec fails
[22:22:39] <Dark_Shikari> Yeah
[22:22:42] <Dark_Shikari> posix_spawn
[22:23:08] <mru> spawn is much easier to implement on an mmu-less system
[22:23:13] <mru> that is the main rason it exists
[22:23:16] <mru> reason
[22:23:17] <jannau> mru: windows has an horrendous CreateProcess with 10 parameters
[22:23:21] <mru> I nkow
[22:23:24] <mru> is it only 10?
[22:23:25] <Dark_Shikari> posix_spawn is not really much better.
[22:23:27] <Dark_Shikari> it's pretty messy too
[22:24:05] <jannau> mru: it was 10 at some point, maybe they've added more
[22:24:12] <mru> that's because you have to pass through a function interface everything you'd otherwise do programmantically between fork and exec
[22:24:18] <mru> or just prior to fork
[22:24:59] <jenk> what's the best m odel?
[22:25:03] <mru> but regardless of all that, fork+exec does pretty much the same as createprocess
[22:25:11] <mru> but a million times faster
[22:25:13] <jenk> i bet plan9 rules
[22:25:14] <mru> how is that?
[22:25:18] <mru> plan9 stinks
[22:25:20] <mru> it's unusable
[22:25:24] <jenk> well yeah
[22:25:33] <jannau> mru: not everything. you have to call a different function for setuid
[22:25:35] <mru> too damn purist
[22:25:38] <Dark_Shikari> mru: but it's plan 9!
[22:25:47] <mru> so pure it's empty
[22:25:50] <Dark_Shikari> plan 9 is the ron paul of operating systems.
[22:26:03] <jenk> i jsut think of plan9 as unix with some forethought put into it
[22:26:07] <jenk> instead of making shit up as you go along
[22:26:18] <mru> that was the original idea
[22:26:33] <mru> but they got so caught up in perfecting everything that it never became usable
[22:26:49] <jenk> ah
[22:28:37] <Dark_Shikari> http://wiki.videolan.org/X264_TODO
[22:28:40] <Dark_Shikari> damn, this is becoming kinda long
[23:20:35] <mru> hah, that "perfect" compiler fails worse than anything I've seen so far
[23:21:19] <mru> apart from being generally awkward in every way, it doesn't even support int64_t
[23:21:23] <Dark_Shikari> mru: ?
[23:22:03] <mru> http://compcert.inria.fr/
[23:23:58] <Dark_Shikari> mru: does it pass tests?
[23:24:11] <mru> it can't compile anything
[23:24:20] <Dark_Shikari> is that just due to being limited?
[23:24:20] <Dark_Shikari> or what
[23:24:21] <kierank> does tcc compiled ffmpeg?
[23:24:26] <kierank> compile*
[23:24:27] <mru> at least nothing more complicated than hello world
[23:24:57] <mru> and it compiled two files in ffmpeg, failed on the third
[23:25:13] <mru> libavutil/common.h:166: syntax error.
[23:25:19] <Dark_Shikari> oh wow, so that just fails
[23:25:45] <mru> and compiling alldevices.c it used 1.2GB of ram
[23:25:59] <Dark_Shikari> wow.
[23:26:03] <Dark_Shikari> how about h264.c?  before the split? ;)
[23:26:05] <Dark_Shikari> or snow.c
[23:26:10] <mru> I dread to imagine what it would do with, say, mpegvideo_enc.c
[23:26:19] <mru> or motion_est
[23:26:27] <kierank> does http://bellard.org/tcc/ work?
[23:26:33] <mru> no idea
[23:26:35] <mru> probably not
[23:27:02] <Dark_Shikari> iirc tcc wasn't particularly bad, just complete lack of optimization.
[23:27:15] <mru> does it support all the language features we need?
[23:27:24] <Dark_Shikari> probably not gcc-specific stuff like inline asm obviously
[23:27:35] <mru> I mean standard features
[23:28:29] <Dark_Shikari> dunno.  one could probably try.
[23:28:41] <mru> what would be the point?
[23:28:53] <Dark_Shikari> curiosity
[23:28:55] <Dark_Shikari> killing cats.
[23:29:26] <kierank> 4chan will come and get you
[23:29:35] <mru> cats are nice
[23:31:42] <Dark_Shikari> Hmm.  I wonder what features we're still missing for http://wiki.videolan.org/X264_TODO .
[23:31:47] <Dark_Shikari> besides "take over the world"
[23:34:39] <kierank> emergency mode?
[23:35:01] <kierank> oh nm you have that
[23:35:08] <Dark_Shikari> no I don't
[23:35:09] <Dark_Shikari> let me add that
[23:35:21] <J_Darnley> "Troll some 'people' with a runtime vp8 option"
[23:36:02] <Dark_Shikari> done
[23:36:35] <mru> troll BBB into working on xvp8
[23:36:40] <Dark_Shikari> done
[23:36:45] <Dark_Shikari> what J_Darnley said, that is
[23:36:49] <Dark_Shikari> BBB is just lazy