[FFmpeg-devel-irc] IRC log for 2010-06-01

[irc at mansr.com]

[00:32:38] <peloverde> I've commented on AAC mapping and SBR backporting, was anyone else waiting on stuff from me?
[00:56:43] <lu_zero> welcome janneg =)
[00:59:24] <janneg> lu_zero: thanks
[01:00:40] <janneg> peloverde: I think I'll look into latm since paul has vanished
[01:06:38] <peloverde> janneg, ok thanks
[01:06:46] <peloverde> if you need PS stuff pull from my git
[01:07:24] <peloverde> I integrate patch feedback there during review so it should always be best/most-correct
[01:25:20] <Kovensky> <saintdev> arch broke for me within 3 days... <-- doing it wrong
[01:26:00] <Kovensky> <j-b> peloverde: Arch <-- arch is mostly unpatched and has an interesting package build system, you may want to try it
[01:26:48] <peloverde> I'll consider it, it does seem somewhat interesting
[01:27:26] <saintd3v> Kovensky: i'm completely used to doing everything myself, all i did was inatall, then update using pacman
[01:27:32] <saintd3v> and broken system
[01:27:51] <saintd3v> well more specifically X died
[01:28:44] <Kovensky> hm, I wonder if you did it during the Xorg 1.6 debacle
[01:29:22] <Kovensky> <@Dark_Shikari> The solution involved typing a variety of commands once logged in. <@Dark_Shikari> This doesn't help, since the bug is that the KEYBOARD IS BROKEN <-- what about booting in runlevel 2 and running them there instead
[01:29:25] <saintd3v> dunno, i have friends that use arch and swear by it
[01:30:03] <Kovensky> oh wait, ubuntu has no root password, in b4 runlevel 2 doesn't work
[01:30:18] <Kovensky> well, either that or it'll give permission to anyone that boots in runlevel 2
[01:41:44] <j0sh_> lu_zero: why do all my base64 requests get a rREVTQ1JJQkUgcnRzcDovL2xvY2FsaG9zdDo0NTY3L2NhdGhlZHJhbC5tcDQgUlRTUC8xLjANCkFj
[01:41:50] <j0sh_> oops
[01:42:01] <j0sh_> i mean, why do they all get a rtsp 400 error
[01:42:17] * j0sh_ curses his touchpad
[01:43:17] <Compn> at least you didnt paste something embarrassing
[01:43:18] <Compn> :P
[01:44:15] <j0sh_> this isnt the first time its happened, im waiting for the day i have something embarrassing in the copy buffer
[03:27:14] <Yuvi> does intra pred in h.264 use samples from before the loop filter?
[03:27:41] <Dark_Shikari> yes
[03:27:50] <Dark_Shikari> hence intra_border_backup
[03:28:35] <Yuvi> what does lavc do?
[03:28:51] <Dark_Shikari> same as x264
[03:28:59] <Dark_Shikari> it stores the intra pred pixels in an array
[03:29:05] <Dark_Shikari> called intra_border_backup
[03:29:06] <Dark_Shikari> then deblocks
[03:29:11] <Dark_Shikari> then it predicts out of that array
[03:29:21] <Yuvi> it'd be called something else then, git grep intra_border_backup shows nothing
[03:29:31] <Dark_Shikari> ok, then look in x264.
[03:29:54] <Dark_Shikari> oh
[03:29:58] <Dark_Shikari> backup_mb_border
[03:30:00] <Dark_Shikari> xchg_mb_border
[03:30:01] <Dark_Shikari> etc
[05:32:58] <lu_zero> yawn
[05:33:52] <lu_zero> j0sh_: how so?
[05:34:11] <Tjoppen> god morgon
[05:34:20] <lu_zero> yawn morning
[05:35:12] <lu_zero> j0sh_: send an email with the whole messages (possibly the wireshark tcp conversation text dump)
[05:48:19] <j0sh_> lu_zero: ok i'll grab some dumps
[05:48:58] <j0sh_> lu_zero: its probably something stupid on my end, since im getting the same error with feng and dss
[05:50:04] <lu_zero> let's find out what's wrong =)
[05:50:39] <lu_zero> you can use the latest vlc (and live555) to check the http-tunnel
[05:51:19] <lu_zero> bbl
[06:14:15] <j0sh_> lu_zero: vlc works, but i dont see a significant difference in the wireshark at first glance
[06:14:26] <j0sh_> i probably need sleep
[06:27:19] <av500> https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/7c38347e9c043620#
[06:27:29] <av500> google fell into the ffvorbis trap?
[06:27:40] <Dark_Shikari> yup
[06:27:44] <Dark_Shikari> youtube encoded all their videos with ffvorbis
[06:27:46] <Dark_Shikari> and still haven't fixed it
[06:27:49] <Dark_Shikari> and afaik they're still doing it
[06:28:34] <peloverde> It's bloltastic
[06:29:17] <CIA-92> ffmpeg: siretart * r23399 /branches/ (0.6 0.6/ffmpeg.c):
[06:29:17] <CIA-92> ffmpeg: ffmpeg: fail if user selected codec is experimental and strict_std_compliance > experimental
[06:29:17] <CIA-92> ffmpeg: backport r23397 by janne
[06:29:29] <peloverde> ^how relevant
[06:30:43] <CIA-92> ffmpeg: siretart * r23400 /branches/ (0.6 0.6/ffmpeg.c):
[06:30:43] <CIA-92> ffmpeg: ffmpeg: offer alternatives for experimental codecs if they exist
[06:30:43] <CIA-92> ffmpeg: backport r23398 by janne
[06:36:28] <lu_zero> ^^;
[06:57:47] <CIA-92> libswscale: siretart * r31298 /trunk/ (3 files in 2 dirs):
[06:57:47] <CIA-92> libswscale: remove palette8torgb15 and palette8tobgr15
[06:57:47] <CIA-92> libswscale: They contain exactly the same code as their 16bit variants, so this is
[06:57:47] <CIA-92> libswscale: effectively code de-duplication.
[07:08:57] <andoma> peloverde: fwiw, that dupe-channel AAC patch fixes playback for one of my previously undecodable 5.1 files, looks good imho
[07:09:11] <peloverde> ok, thanks
[07:46:08] <vipw> what would be the consequence of changing RTSP_DEFAULT_NB_AUDIO_CHANNELS from 2 to 1?
[07:47:16] <CIA-92> ffmpeg: mstorsjo * r23401 /trunk/libavformat/ (10 files): Declare the url_write buffer parameter as const
[07:47:33] <vipw> i saw a few emails from a couple years back, http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2007-November/012266.html
[07:48:35] <vipw> as i understand from the SDP rfc (2327), the default should be 1
[07:50:12] <wbs> vipw: I think that makes sense, feel free to send that as a patch with this motivation included (quoting the relevant sections of the RFC) to ffmpeg-devel
[07:53:59] <KotH> salve!
[07:54:06] <av500> grüezi
[08:01:12] <kshishkov> привет
[08:08:04] <CIA-92> ffmpeg: stefano * r23402 /trunk/libavcodec/ (opt.c eval.c avcodec.h eval.h ratecontrol.c):
[08:08:04] <CIA-92> ffmpeg: Make ff_parse_expr() and ff_parse_and_eval_expr() return an int
[08:08:04] <CIA-92> ffmpeg: containing an error code.
[08:08:04] <CIA-92> ffmpeg: Allow these functions to convey the reason of the failure to the
[08:08:04] <CIA-92> ffmpeg: calling function, failure which is not always due to a parsing error
[08:08:04] <CIA-92> ffmpeg: but it may depend for example on a memory problem.
[08:08:05] <CIA-92> ffmpeg: Also fix several potential memleaks.
[08:08:05] <CIA-92> ffmpeg: stefano * r23403 /trunk/libavcodec/ (eval.c eval.h): (log message trimmed)
[08:08:06] <CIA-92> ffmpeg: Cosmetics: rename ff_parse_expr() and ff_parse_and_eval_expr() parameters:
[08:08:06] <CIA-92> ffmpeg: const_name -> const_names
[08:08:07] <CIA-92> ffmpeg: const_value -> const_values
[08:08:07] <CIA-92> ffmpeg: func[12]_name -> func[12]_names
[08:08:08] <CIA-92> ffmpeg: func[12] -> funcs[12]
[08:08:08] <CIA-92> ffmpeg: All these parameters contain a list of values, using plural names for
[08:08:24] <CIA-92> ffmpeg: stefano * r23406 /trunk/libavcodec/eval.c: Fix eval-test compilation.
[08:09:26] <KotH> j-b: did you get your svn account for dvdnav?
[08:11:16] <j-b> not yet
[08:11:35] <KotH> good, i'll create you one after the coffee break :)
[08:12:06] <av500> create me a coffee please
[08:13:22] <superdump> jag också
[08:13:26] <kshishkov> av500: .ch is not famous for coffee, ask somebody like wbs instead
[08:13:30] <superdump> mmmm kaffe
[08:13:43] <andoma> kaffe it is!
[08:13:55] <j-b> Can I have some coffee too?
[08:13:55] <av500> kshishkov: KotH is not your pure bred swiss, is he?
[08:13:56] * kshishkov drycka inte kaffe
[08:14:06] <superdump> jag vill ha frukost nu!
[08:14:24] * superdump looks at andoma
[08:14:33] <kshishkov> av500: good point but he's not in Turkey anymore
[08:14:43] <av500> nor in Kansas
[08:15:09] <av500> j-b: you did not have a coffee + cigarette for breakfast?
[08:16:07] <j-b> I don't smoke ... (anymore)
[08:23:23] <vipw> wbs: ok, i sent a patch
[08:26:42] <j-b> KotH: I am just very glad the work on dvdnav is resuming
[08:26:51] <j-b> and that we stop to have 20 forks of it
[08:29:02] <spaam> just wait until uau make one..
[08:43:44] <KotH> j-b: that was the reason why nico originally forked it
[08:44:07] <thresh> to have 20 forks?
[08:44:08] <j-b> well, true, but it was quite calm since the last 4 month
[08:44:27] <j-b> and handbrake and VLC had still quite a few patches
[08:44:38] <j-b> it is cool that this is getting solved
[08:54:10] <j-b> So far I haven't seen any lawyer or person involved with the two projects claim that it is. And random people on the internet don't count."
[08:54:21] <j-b> peloverde: you are random people on the internet
[08:57:34] <lu_zero> j-b: uh?
[08:57:38] <lu_zero> (good morning btw)
[09:00:02] <wbs> vipw: I can't see any such patch on ffmpeg-devel
[09:02:18] <j-b> lu_zero: the blog from gnome
[09:02:42] <KotH> j-b: where is that quote from?
[09:03:14] <vipw> yeah, i can't see it either
[09:03:55] <vipw> if it doesn't show up today i'll resend it
[09:04:49] <vipw> ffmpeg-devel at mplayerhq.hu is the address, right?
[09:05:30] <wbs> yes, but you need to be subscribed, too
[09:06:00] <vipw> oh, just what i always wanted
[09:06:09] <j-b> http://blogs.gnome.org/otte/2010/05/31/youtube-out-of-the-box/
[09:06:26] <kshishkov> wasn't it posted here yesterday?
[09:06:34] <j-b> yes
[09:06:47] <j-b> but the comment about 'random people' is new
[09:08:49] <KotH> lol
[09:09:10] <av500> j-b: the logic is good, unless a lawyer says otherwise, licences are compatible by default....
[09:09:16] <KotH> "i'm too lazy to check the facts myself, so i trust someone who is paid to lie to other people"
[09:11:02] <kshishkov> KotH: yes, that's what voting is all about
[09:11:26] <j-b> av500: I like that one too :D
[09:15:18] <hyc> wbs: hmmm... sounds like you're saying I need to make these things into public APIs
[09:15:37] <hyc> otherwise, have to split it apart again and back to square 1 re: code cuplication
[09:15:42] <wbs> hyc: yes, if lavf is supposed to use something from lavc, it should be a public API
[09:15:45] <wbs> yeah
[09:16:46] <hyc> I figure I'd wait for Michael to comment on the h264.c patches first
[09:16:54] <wbs> yeah, that's probably a good idea
[09:19:28] <av500> file under "codec wrappers to hate": https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/a4c884f5c637abad#
[09:22:44] <scaphilo> hi there i have a syntax error in the intreadwirte.h, has anyone an idea why? I wantet to build ffmpeg with my own makefile.http://dpaste.com/201762/
[09:23:09] <scaphilo> its because i wantet to use hardwaretimers on my embedded system
[09:23:28] <av500> and therefore you need your own makefile?
[09:24:05] <av500> a hardwaremakefile?
[09:24:06] <scaphilo> its easyer yes, but if ffmpeg does not compile with a automakefile ill finde an other way
[09:24:16] <scaphilo> for the niosII
[09:24:35] <scaphilo> it already compiles and runs with the ffmpeg make file
[09:24:42] <av500> so?
[09:25:12] <hyc> that wasn't challenging enough...
[09:25:20] <scaphilo> but now i want to get the exact time of a macroblock decoding or macroblock encoding
[09:25:26] <scaphilo> :-)
[09:25:37] <av500> so?
[09:25:47] <av500> why do you need a different makefile for that?
[09:26:55] <scaphilo> hmm when you ask me like that ... i have to think again. It works of cause but its a little bit more complicated
[09:27:23] <scaphilo> because the hardware timer are defined in an other library
[09:27:40] <av500> so, link against that lib
[09:27:55] <scaphilo> your right hmm i was sure there is a problem...
[09:28:48] <scaphilo> so you think there is no easy way to make a build of ffmpeg with a automake file
[09:29:10] <scaphilo> i wrote a script to set all includes in the right way already
[09:29:13] <wbs> easy or not, it's not supported and it's all up to you if you want to do it that way, but don't expect any support in that case
[09:29:21] <av500> scaphilo: and what for?
[09:29:56] <scaphilo> ah your right will find an other way it s better, perhaps ill have to come back because i was sure there is a problem i cant solve
[09:30:56] <scaphilo> anyone here that can tell me how much faster the arm uc is with the asm files than with the c files?
[09:31:11] <Dark_Shikari> "uc"?
[09:31:20] <scaphilo> well the transcoding
[09:31:31] <scaphilo> is that about a factor 2 or more?
[09:31:48] <Dark_Shikari> wtf is a uc
[09:31:53] <scaphilo> microcrontroller
[09:33:04] <Dark_Shikari> but what are you doing with ffmpeg
[09:33:06] <Dark_Shikari> faster at what
[09:33:12] <scaphilo> how much faster is it on the i386 with the asm files? Has anyone tested that
[09:33:27] <scaphilo> the frame transcoding from mpeg2 to mpeg4
[09:33:57] <scaphilo> i currently have about 10fps with a 320x180 video
[09:34:14] <Dark_Shikari> what arm?
[09:34:23] <scaphilo> niosII (Altera)
[09:34:43] <scaphilo> on the computer its without asm about 800 fps
[09:34:43] <Dark_Shikari> v7, v6, v5...?
[09:35:01] <scaphilo> are there verions?
[09:35:06] <Dark_Shikari> lo
[09:35:08] <Dark_Shikari> l
[09:35:26] <scaphilo> hey man what you mean
[09:35:53] <Dark_Shikari> I mean that you should know what instruction set your own CPU uses.
[09:36:49] <scaphilo> am ... no not yet. ARM processors use different instruction sets but im not sure NIOSII does
[09:36:53] <hyc> aww... I don't know which SSEx my CPU supports....
[09:37:37] <scaphilo> but that does not mather now, i was just wondering if it makes sens to write asm files for the nios
[09:38:02] <scaphilo> perhaps its better to leave it with c flies and make some hardware for mb-transcoding
[09:38:08] <Dark_Shikari> I can't answer that until I know what instruction set it uses.
[09:38:45] <av500> http://en.wikipedia.org/wiki/Nios_II
[09:39:19] <Dark_Shikari> er... that's not an ARM
[09:39:27] <av500> no
[09:39:31] <scaphilo> yes thats what i said
[09:40:10] <scaphilo> how much faster is a transcoding process with this asm files on the computer?
[09:40:18] <scaphilo> is it a factor 2 or more
[09:40:20] <Dark_Shikari> "asm" does not magically make things faster
[09:40:22] <Dark_Shikari> SIMD makes things faster
[09:40:25] <Dark_Shikari> asm is just a way to write SIMD
[09:40:30] <Dark_Shikari> if your processor has no SIMD unit, asm is useless
[09:40:42] <scaphilo> ah ok i see
[09:40:45] <av500> scaphilo: well, you are on an FPGA, make a SIMD unit
[09:40:51] <scaphilo> exaclty
[09:41:00] <av500> Dark_Shikari: instruction set looks pretty basic
[09:41:11] <Dark_Shikari> av500: or just make an idct unit
[09:41:12] <Dark_Shikari> and dct unit
[09:41:14] <Dark_Shikari> and mc unit
[09:41:16] <Dark_Shikari> ;)
[09:41:19] <Dark_Shikari> and sad unit
[09:41:22] <scaphilo> thats what im going to do but  i was wondering if there is any benefit of writing some parts in asm
[09:41:24] <av500> and happy unit
[09:41:36] <scaphilo> i have no dct anymore ;-)
[09:41:41] <scaphilo> no mc/me anymore
[09:41:54] <Dark_Shikari> then what in the world would you asm?
[09:42:07] <Dark_Shikari> how about you do a profile before talking about asm?
[09:42:20] <av500> asm makes everything faster
[09:42:35] <wbs> it's like magic
[09:42:37] <Dark_Shikari> yes, via MAGIC
[09:42:42] <scaphilo> i first have to find the critical part. thats why i want to implement a hardware timer (what my first question was about)
[09:42:46] <kshishkov> and
[09:42:50] <scaphilo> :-)
[09:42:54] <Dark_Shikari> scaphilo: er...
[09:42:55] <kshishkov> gcc -O-3 makes everything slower
[09:42:57] <Dark_Shikari> why not just run it on your cpu?
[09:42:58] <Dark_Shikari> and oprofile it?
[09:43:02] <Dark_Shikari> sure it won't be 100% accurate
[09:43:05] <Dark_Shikari> but it'll be decently close.
[09:43:28] <av500> not sure he runs linux
[09:43:37] <av500> scaphilo: do you?
[09:43:44] <scaphilo> im running linux but i dont know what oprofile does
[09:43:49] <Dark_Shikari> man oprofile
[09:43:49] <av500> google knows
[09:43:50] <scaphilo> ah you mean on the nios
[09:43:55] <av500> yes
[09:44:02] <scaphilo> no theres no linux
[09:44:04] <scaphilo> sorry
[09:44:08] <scaphilo> missunderstood that
[09:44:48] <scaphilo> the only thing this chip does is read file over usb transcode and write it back
[09:44:49] <spaam> kshishkov: so with -O+9001 it going to be fast?
[09:44:56] <Dark_Shikari> scaphilo: so profile it on your computer
[09:44:58] <Dark_Shikari> not the nios
[09:45:28] <scaphilo> that sounds like a good idea :-)
[09:46:02] <scaphilo> but my customer is a bit strange as you know and he wants hardware "profiling"
[09:46:35] <scaphilo> thank you for all ideas
[09:46:47] <kshishkov> spaam: no, with -O9001 it will produce the same crap on any GCC version
[09:46:49] <Dark_Shikari> sure, you can do hardware profiling later
[09:46:55] <Dark_Shikari> But why not start with something you can do here and now
[09:47:30] <av500> scaphilo: this is a commercial project?
[09:47:39] <scaphilo> unfortunatly i have a meeting on frieday about that point
[09:47:41] <scaphilo> yes it is
[09:47:49] <Dark_Shikari> oprofiling takes 5 minutes
[09:47:51] <Dark_Shikari> do it now
[09:48:07] <scaphilo> ? thats that easy never did that befor
[09:48:14] <scaphilo> with what tool?
[09:48:31] <scaphilo> ill google
[09:48:44] <Dark_Shikari> ....
[09:48:45] <Dark_Shikari> WITH OPROFILE
[09:48:48] <Dark_Shikari> ..................
[09:49:02] <Dark_Shikari> You know how you vacuum your house?  WITH A VACUUM.
[09:49:11] <scaphilo> shame on me
[09:49:29] <scaphilo> ill google now
[09:49:48] <av500> Dark_Shikari: open gas valve, wait, then throw match works as well....
[09:50:30] <KotH> .o0(note to self, never enter a house that av500 has cleaned up)
[09:50:35] <kshishkov> av500: s/throw/light a/, that's enough
[09:50:52] <av500> kshishkov: if you want new haircut at the same time, yes
[09:50:56] <kshishkov> KotH: but it will be cleaned really good - and disinfected in the same time too!
[09:51:59] <hyc> dunno where these guys learn to be software developers, if at all. anybody who thinks you need to replace the makefile just 'cause you want to add a library or include path ... sigh...
[09:52:26] <j-b> hyc: have you been to a "modern" CS course?
[09:52:41] <KotH> hyc: people who learn programming in companies never learn how to do things the right way
[09:52:51] <av500> hyc: at the "<random indian city> Institute of Technology"
[09:53:13] <kshishkov> j-b: I don't think they learn about Makefiles at all there
[09:53:13] <ohsix> or just because you don't like autotools ;]
[09:53:14] <KotH> hyc: you've to be very luck to have someone to tutor you. in most companies you come fresh out of school and are expected to be a competent programmer
[09:53:16] <j-b> even in the US
[09:53:52] <hyc> KotH: yeah, I'd expect that too. I was a competent programmer before I got into college.
[09:53:53] <j-b> kshishkov: well, once you have done the "java" course, you think that any modification of the build-system must be rewritten for a tiny change
[09:54:33] <KotH> hyc: you are an exception. most people learn the basics of programming in school/college/university, then enter a company, never learning what it really means to do software development
[09:54:40] <Kovensky> j-b: build system? what build system?
[09:54:48] <kshishkov> j-b: actually I did
[09:54:53] <Kovensky> don't you just click the green arrow on the compiler?
[09:54:59] <KotH> hyc: heck, me, with my very low programming skills, am one of the most competent coders in our company
[09:55:31] <av500> Kovensky: I call c:\compile.bat....
[09:55:46] <hyc> I find that bizarre. if you apply for a programming job in a company, that ought to mean you're able to do the job. :P
[09:55:53] <av500> lol
[09:55:59] <Kovensky> av500: better than my colleagues then; they call an IDE a "compiler" and can't do squat outside of one
[09:56:05] <KotH> hyc: able != fully trained with 10y experience
[09:56:08] <Kovensky> av500: blame my professors for that too <_<
[09:56:18] <j-b> lol... 99% of people who apply to programming jobs don't have a clue about programming
[09:56:25] <KotH> hyc: in all other jobs, people expect you to know the basics and will train you until you know the rest too
[09:56:29] <av500> Kovensky: no, professor is not there to teach you how a makefile works
[09:56:36] <Kovensky> all my programming professors so far have been incompetent; except for one but he quit during the first course we had with him so we were back to the incompetent ones
[09:56:40] <KotH> hyc: it's just with programming that people expect that someone fresh from school has 10y of experience
[09:56:43] <ohsix> hiring is a risk, too; sometimes you just have to live with the quality of the applicants, people make more money doing sillier things
[09:56:49] <Kovensky> av500: no, but he shouldn't tell you that the IDE is a compiler
[09:56:57] <Kovensky> and other dumb stuff
[09:57:24] <Kovensky> like writing { int ary[10]; int i; for (i = 1; i <= 10; i++) { do_stuff_with(ary[i]); }
[09:57:36] <av500> Kovensky:  dont be so hard on them, some used to be physics phds selling fries...
[09:57:39] <ohsix> he probably doesn't know what a linker is either; and barring having to work with a linker or do something outside of the ide it might as well not matter
[09:57:51] <kshishkov> Kovensky: sounds like Pascal convert
[09:57:56] <hyc> cripes. what did these *professors* study? most of my professors were all mainframe hackers in the '60s.
[09:58:05] <Kovensky> kshishkov: he once wrote an entire program in pascal inside dev-c++ (lol)
[09:58:14] <KotH> hyc: mainframe hackers died 10y ago
[09:58:15] <KotH> :)
[09:58:27] <Kovensky> and then spent 5 minutes trying to understand the syntax errors until he noticed what he did
[09:58:27] <av500> KotH: no
[09:58:37] <ohsix> died/absorbed by banking institutions still running cobol
[09:58:57] <KotH> hyc: i once took a class in networking. our prof, one of the "renowed networking experts in europe" made at least one major mistake per hour...
[09:59:20] <hyc> gack
[09:59:31] <hyc> well, yeah, a lot of my profs did too
[10:00:35] <KotH> and correcting him each time was the right decission: after that course he knew me well enough so that i got the credit points for another class of his w/o actually going there :)
[10:00:47] <hyc> and some just had outdated info. my Op/Sys prof did the original work on the UMich mainframe OS, but I was also a part time employee at the Computing Center when I got to that class.
[10:01:22] <hyc> so my day job was rewriting bits of ths OS, which I then got to tell him "no, it doesn't work that way any more" in the middle of lecture...
[10:02:03] <hyc> KotH: nice! never got free credit before ;)
[10:02:26] <spaam> KotH: so he was your new BFF? ;)
[10:02:31] <KotH> hyc: you just have to be arrogant enough ;)
[10:02:39] <KotH> spaam: BFF?
[10:02:49] <spaam> KotH: Best Friends Forever
[10:03:41] <KotH> spaam: nah..
[10:03:50] <KotH> spaam: i'm quite sure he didnt like me :)
[10:04:22] <KotH> spaam: or would you like a student, not even half your age, correcting you all the time infront of 200-odd people?
[10:04:56] <kshishkov> KotH: guess who was that student in my school?
[10:05:04] <hyc> lol
[10:05:17] <KotH> kshishkov: hmm... your brother? ;)
[10:05:19] <hyc> well, he gave you credit for another course, and probably didn't have to.
[10:05:28] <hyc> pr perhaps that was just his way of keeping you out of his class.
[10:05:34] <kshishkov> KotH: unlike you I'm the only child
[10:05:35] <spaam> KotH: no. :)
[10:05:38] <KotH> hyc: more likely ;)
[10:05:38] * av500 can understand that
[10:06:51] <hyc> personally I was mortified that they were teaching binary arithmetic in a 300-level class, and most of my classmates had never seen it before
[10:07:11] <KotH> huh?
[10:07:17] <KotH> here, we had that in highschool
[10:07:33] <KotH> (and a repetion in first semester math)
[10:07:44] <hyc> even crazier since we had a 200-level course in logic design
[10:07:50] <KotH> o_0
[10:08:23] <hyc> people who didn't make the connection between boolean,s transistors, and bits. incredible that they graduated.
[10:08:25] <av500> hyc: I am sure there is non-binary logic :)
[10:08:43] <Kovensky> lulz
[10:08:48] <Kovensky> tales of college incompetence~
[10:08:54] <av500> inb4: http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx
[10:09:12] <Kovensky> kill -EOF av500
[10:09:17] <Kovensky> as if :/
[10:09:24] * Kovensky goes to college
[10:09:53] <hyc> heh
[10:10:09] <hyc> well, LDAP filter assertions are tri-state: true, false, undefined
[10:11:15] <hyc> ooo, vdpau/vaapi/xvba
[10:11:27] <KotH> hyc: 1149 9-valued logic :)
[10:11:43] <hyc> I guess the most obvious point is that vdpau actually works, as opposed to xvba
[10:11:52] <hyc> KotH: 1149?
[10:11:59] <KotH> ieee1149
[10:12:01] <kshishkov> hyc: actually n-state logic is popular in modelling electronic schemes
[10:12:18] <KotH> hyc: quite old ieee standard defining logic values for simulation in vhdl
[10:12:22] <iive> hyc: do you have some link with actual content about xvba?
[10:12:25] <KotH> hyc: among other things
[10:12:41] <iive> all my googling ends in press releases.
[10:12:53] <hyc> iive: not much beyond what I've read on phoronix
[10:12:57] <hyc> which is all depressing
[10:13:17] <hyc> http://www.phoronix.com/forums/showthread.php?t=19983
[10:13:43] <hyc> the last post by Gwenole Beauchesne is the clincher I think
[10:14:08] <hyc> http://www.phoronix.com/forums/showpost.php?p=131086&postcount=822
[10:18:41] <hyc> well I guess we could go back to decimal computers or someesuch
[10:19:07] <hyc> if this memristor stuff pans out we'll be doing analog computing...
[10:19:30] <ohsix> stateless computing
[10:19:31] <KotH> which reminds me, i still havent read how the memristor works ^^'
[10:20:05] <KotH> ohsix: already known
[10:20:11] <ohsix> its a programmable resistor; like you can program a transistor by its base, except it holds its value when its removed
[10:20:14] <KotH> ohsix: search for "adeabatic switching"
[10:20:30] <KotH> ohsix: i know what a memristor is, i just dont know how it works in detail
[10:21:21] <iive> hyc: once again, articles... is there some code could be run, even if it have a pile of bugs?
[10:21:54] <hyc> iive: yes, but according to posts in that thread, you won't get much from it
[10:22:16] <iive> i want code... not articles and endless chain or url to other articles. pleaseeee
[10:22:28] <hyc> http://www.splitted-desktop.com/~gbeauchesne/libva/
[10:22:59] <hyc> http://www.splitted-desktop.com/~gbeauchesne/
[10:24:54] <KotH> hyc: btw: analog computing is a dead end
[10:25:06] <hyc> It also doesn't help that AMD hasn't made their API public / open source
[10:25:15] <hyc> KotH: dead end? why?
[10:25:26] <KotH> hyc: we've been there and it didnt work out and got replaced by digital computation in the 60s and 70s
[10:25:51] <KotH> hyc: it is very hard to have fast and exact computation, heck even just exact computation is very difficult
[10:26:05] <KotH> hyc: small variations in device characteristics have large effects on the results
[10:26:16] <hyc> I think some of the path we've taken was dictated by the transistor
[10:26:28] <hyc> memristor points down a different path...
[10:26:49] <KotH> hyc: just as an example: the average transistor that comes out of a factory can have a variation in amplification in the range of two magnitutes
[10:27:08] <KotH> bbl...lunch time
[10:28:25] <hyc> I think binary/digital computation is hitting a wall. everything I read about going forward is about error correction and fault tolerance, because precise results cannot be relied upon at the component level
[10:29:05] <hyc> magnetic disk drives have been there for years already - PRML heads...
[10:30:11] <hyc> these memristor researchers are talking about them in terms of neurons - a unit is both a data storage and a computation unit at once
[10:30:42] <hyc> as opposed to current transistor-based technology, processors distinct from RAM
[10:31:27] <hyc> and also, nanoscale, talking about inherently unreliable / uncontrollable processes, which you make up for by massive redundancy
[10:32:14] <ohsix> well you can pattern them in place into logic gates due to the way they function; or you can use that same state for memory type storage, all that persists if power is removed
[10:32:22] <hyc> if they're really going to move forward with this model, emulating organic brains, it's all going to be analog
[10:32:58] <twnqx> which basically means
[10:33:09] <twnqx> you lose all the precision or all the speed
[10:33:26] <hyc> twnqx: yes and no
[10:33:32] <ohsix> nets solve problems by thresholding their inputs
[10:33:36] <hyc> you have massively parallel processing
[10:34:03] <twnqx> my brain has that, too
[10:34:17] <twnqx> still takes me some time do calculate 16bit multiplications
[10:34:21] <twnqx> to*
[10:34:24] <hyc> yes. you may not be able to solve a single long sequence of calculations
[10:34:27] <hyc> quickly
[10:34:38] <hyc> but you can solve millions of other calculations simultaneously
[10:34:51] <twnqx> that doesn't help for the applications of computers
[10:34:59] <hyc> true
[10:35:06] <hyc> it may very well be a dead-end in that respect.
[10:35:32] <hyc> not much point in developing a machine that is just as slow and fallible as a human.
[10:37:02] <hyc> and I think that's ultimately where these large mesh networks are heading...
[10:37:43] <hyc> but ya never know. our brains do all these computations all the time, at a level beneath our consciousness
[10:38:23] <hyc> kinda wonder why we don't have JTAG - did we really evolve this far without any form of introspection capability?
[10:39:32] <hyc> it's like having a powerful CPU hidden under so many API abstraction layers that as an end-user you no longer have the ability to ask it "print x * 2"
[10:40:55] <twnqx> which institution did you flee from? :X
[10:41:42] <hyc> :P
[10:44:17] <hyc> come on, you don't think reverse-engineering the human brain would be a cool hack?
[10:48:50] <twnqx> having backup & restore would be... interesting, indeed
[10:49:24] <twnqx> however there's more to it than just the neural network.
[10:58:12] <Tjoppen> uncompressed 4k video in DPX format. a mere 19 GiB för 16 seconds
[10:58:26] <Tjoppen> *for
[11:03:42] <KotH> hyc: the error correction systems of modern cpus is not because components are a little bit out of spec, but because whole components fail
[11:04:08] <KotH> hyc: this is mostly due to the extremely small sizes of todays electronics
[11:04:19] <hyc> kotH: sure. and that gets worse as sizes decrease
[11:04:26] <KotH> hyc: you'd have that problem with analog electronics too... in addition to the hardly controllable specs of the components
[11:04:43] <merbzt> Tjoppen: care to resurrect the dpx patch ?
[11:04:44] <KotH> hyc: yes, if we stick to the current technologies
[11:05:05] <KotH> hyc: but all chip manufacturers know that by 2015 there needs to be a new technology to replace current CMOS
[11:05:42] <KotH> hyc: if it isnt introduced by 2020, the current development of electronics and with it all of the computer and communication development will grind to a halt
[11:06:29] <merbzt> KotH: so complete units in cpu's can fail ?
[11:07:01] <merbzt> but continue to work via replacement paths ?
[11:07:03] <KotH> merbzt: complete transistors
[11:07:09] <merbzt> ok
[11:07:10] <Tjoppen> merbzt: I see CODEC_ID_DPX.. I assume it's not in?
[11:07:15] <KotH> merbzt: and with the transistors complete subuints
[11:07:28] <Tjoppen> I have the standard in my hand (well, on screen)
[11:07:30] <KotH> merbzt: which is different from the variations in the specs of analog components
[11:07:39] <hyc> KotH: again, the memristor guys are talking about a mesh of billions of memristors, of which some percent are already flawed
[11:08:01] <hyc> so you have to have noise tolerance / fault tolerance designed in from the start
[11:08:08] <merbzt> Tjoppen: there are patches for dpx decode, just needs some fixing up, scavange the mailinglist
[11:08:17] <KotH> hyc: you have that with curren CMOS processes as well :)
[11:08:50] <Tjoppen> might have a look. I have to wrap DPX in MXF, and possibly transcode it later. in the latter case a codec is needed, but wouldn't hurt to get it done - it's not impossible
[11:08:57] <KotH> hyc: actually, it was always necessary when driving the electronics to their technical limits, no matter which decade it was
[11:09:08] <KotH> hyc: it just different effects you have to account for
[11:09:09] <Tjoppen> although getting all pixel formats it can represent into lavc might be a bit.. interesting :o
[11:09:39] <hyc> kotH: yeah I guess that's true
[11:10:12] <merbzt> Tjoppen: the patch is in review round 13 or something, shouldn't take more then a few hours to get it in
[11:10:27] <KotH> hyc: eg: until in the 80s everyone was using bipolar technology for logic. it was way better than anything cmos could do in most fields
[11:10:44] <hyc> KotH: but it still sounds a little different. with ICs, get defects here and there and you scarp the entire device.
[11:10:49] <hyc> scrap
[11:11:02] <KotH> hyc: but things started to change when the number of transistors per cm^2 increased to a point where the power disipation couldnt be handled with bipolar anymore
[11:11:22] <KotH> hyc: no, scraping whole devices is long gone
[11:11:38] <KotH> hyc: even in the 80s, devices were just down-rated
[11:12:17] <KotH> hyc: the distinction between different frequency classes are just the process variations (aka defects) during production. nothing else
[11:12:55] <KotH> hyc: it's just that the number of parts are now so large, that you cannot reach the high specs of the circuit because 0.001% of the parts have lower specs
[11:13:44] <KotH> hyc: hence they disable full subunits (eg use only 4 of teh 6 available cores). or build multiple units and select the ones used during the last step of production
[11:13:51] <Tjoppen> found the dpx thread. reading it atm
[11:14:06] <Tjoppen> also, might want to add raw image support to mxf demuxer
[11:15:07] <KotH> hyc: the granularity of the redundancy is going down with continously, as people learn how to deal with the additional production complexity
[11:15:08] <hyc> KotH: which puts an upper bound on the size and complexity of individual subunits...
[11:15:18] <hyc> ok
[11:15:18] <KotH> hyc: we already have that
[11:15:51] <KotH> hyc: a chip is bound to about 2x2cm^2 size, due to manufacturing costs and clock distribution issues
[11:16:12] <KotH> hyc: there are hardly any chips that are 3x3cm^2 or larger
[11:16:14] <hyc> yes, that's a complete chip. and now a chip has multiple cores
[11:16:29] <hyc> and distinct cache submodules, etc.
[11:16:54] <KotH> the multi-core aproach grew exactly out of the problem that clock distribution and synchronization became impossible over the whole chip, so they split it into different clock domains
[11:17:27] <KotH> (not to talk about that the signal delay for a signal crossing the chip grew into the region of one clock cycle)
[11:18:05] <Tjoppen> oo, I see rgb48 was added to libswscale at least
[11:18:21] <hyc> right, which is why we're not seeing massive increases in single-threaded processing speed any more
[11:18:22] <Tjoppen> or.. it needs to output something else. hm
[11:19:09] <KotH> hyc: increases? there has not been any increas to speak of since about 2004 :)
[11:19:36] <hyc> KotH: shhhhhhhh, Intel doesn't want anyone to realize that :P
[11:20:09] <KotH> we've actually reached a point where a full multiplication can be done in a single clock cycle, but getting the result anywhere takes 2-3 cylces
[11:20:40] * KotH wonders when the first GALS chips will apear
[11:21:30] <hyc> what, no diamond semiconductors?
[11:21:30] <KotH> though, i think they will first struggle with the issues to get the feature size below 20nm
[11:21:41] <KotH> diamond semiconductors?
[11:21:49] <KotH> diamond has no semiconduction properties
[11:22:15] <hyc> sorry, was remembering some article on how carbon was set to displace silicon
[11:22:25] <hyc> graphite for conduction
[11:22:42] <hyc> diamond for substrate, heat sink
[11:23:16] <KotH> hmm...
[11:23:26] <KotH> graphene layers maybe
[11:23:54] <hyc> yeah, that was probably it
[11:23:58] <KotH> but these are still in early stage of research (until iirc two years ago, there was no good way known to produce single atom graphene layers)
[11:24:24] <KotH> i doubt that we see anything that will be usable for electronics in the next 5 years
[11:24:42] <KotH> if not 10 years
[11:25:24] <KotH> and by that time it might be already too late
[11:25:41] <hyc> too late how, somethin g else better will have come along?
[11:25:42] <KotH> what is an opportunity though, are nanotubes on silicon substrate
[11:25:57] <KotH> yes, development in other fields isnt standing still
[11:26:28] <KotH> it might very well be that we'll have molecular transistors in 10y
[11:26:44] <KotH> ie, transistors implemented in organic/non-organic molecules
[11:27:52] <Tjoppen> merbzt: wait a minute.. there already is a dpx decoder, and it seems to decode my files OK (could transcode to JPEG)
[11:28:30] <hyc> KotH: looking forward to seeing things develop. I recall someone has already developed ATP-powered electronics
[11:28:42] <twnqx> i'd want something like the archos 5 with a 1680x1050 15.4" and tegra
[11:29:01] <thresh> and portable, so you can stick it in your pocket
[11:29:05] <twnqx> how much would building a prototype of that cost...
[11:29:28] <av500> you dont want tegra
[11:29:34] <KotH> hyc: "developed" as in "i have demonstrated, that potentially it might be possible to build anything using this approach in a highly controlled lab enviroment"
[11:29:52] <hyc> twnqx: I'm pretty sure we can get 1920x1080 DLP projectors that fit onto an eyeglass
[11:30:03] <hyc> KotH: yeah, that.
[11:30:12] <twnqx> av500: ok, anything with open source video acceleration and enough horsepower to run gentoo
[11:30:27] <KotH> hyc: from the first results of a lab research it takes quite some time to industrialize it... and sometimes industrialization is not possible
[11:30:36] <av500> twnqx: the tegra does not decode 1080
[11:30:42] <av500> neither open nor closed
[11:30:52] <twnqx> meh
[11:30:55] <KotH> hyc: not to talk about that normal newspapers and magazines exagerate results by quite a few magnitudes
[11:31:15] <KotH> hyc: like the "we have created artificial life" a few weeks ago
[11:31:21] <hyc> ah yes
[11:31:50] <av500> twnqx: i can offer 10"
[11:31:52] <twnqx> is there nothing short of ion than can really drive 2x 1920x1200 and play 1080p video with at least BD bitrates?
[11:32:17] <av500> twnqx: there is ion
[11:32:25] <av500> and intel chipset hw accell
[11:32:31] <twnqx> 10" and HD (at least 1280x720), or something that's to lowres for browsing even?
[11:32:49] <av500> 1280x600 iirc
[11:32:53] <av500> std netbook res
[11:32:53] <twnqx> mh
[11:33:02] <twnqx> yeah, there's a reason why i don't have a netbook
[11:33:07] <twnqx> and that's not money.
[11:33:16] <av500> err, 1024x600
[11:33:30] <twnqx> that's pre-2000 resolutions
[11:33:41] <twnqx> and one of the reasons i refuse all these gadgets
[11:34:03] <av500> I'm sure you lugged around a 20"CRT with you pre 2000....
[11:34:08] <twnqx> 19"
[11:34:10] <twnqx> in 1600x1200
[11:34:29] <twnqx> at 17" in 1280x1024
[11:34:43] <hyc> I still have my 19" 1280x1024 monochrome monitor
[11:34:47] <av500> yes, in you pocket?
[11:34:51] <hyc> on my desk
[11:34:58] <twnqx> i'm not looking for "in my pocket"
[11:35:15] <av500> twnqx: then you are barking up the wrong tree :)
[11:35:17] <twnqx> i'm looking for useable. pocket stuff is like an ipod, play music on it
[11:35:37] <twnqx> well, i asked for pretty specific number :X
[11:36:05] <hyc> I want hi-rez eyeglass displays. seems like they're still a few years away from being decent.
[11:36:27] <av500> and a decent collision warner
[11:36:33] <twnqx> lol
[11:36:43] <hyc> ok, make them semi-transparent
[11:36:50] <twnqx> HUD glasses?
[11:36:54] <hyc> yep
[11:37:07] <KotH> hyc: they have been "a few years away" for years now :)
[11:37:13] <hyc> sigh
[11:37:31] * twnqx remembers laser projection into the eye
[11:37:41] <hyc> last I heard the problem is they don't do well at tricking the eye into perceiving depth
[11:38:13] <av500> twnqx: skip the eye, it has a low bitrate path to the brain anyway...
[11:38:28] <hyc> you need to be able to selectively defocus regions so that the eye's own aiming/focusing mechanisms work
[11:38:41] <twnqx> hyc: just track the eye lense
[11:38:59] <hyc> which means you need several times HD rez to allow you to do the antialiasing and such
[11:39:23] <twnqx> *i* don't mind
[11:39:31] <twnqx> i'd buy a 150dpi 24" display immediately
[11:39:46] <av500> hyc: several times HD for the eye that is said to have 18bit/s to the brain, overkill....
[11:39:47] <twnqx> there's no such thing as "enough" resolution or display space
[11:39:54] <twnqx> 18mbit/s?
[11:39:58] <av500> no
[11:40:03] <av500> quite low bitrate
[11:40:03] <twnqx> 18 bit?
[11:40:13] <av500> I read that somewhere
[11:40:15] <twnqx> i'd consider that unlikely...
[11:40:32] <hyc> hmm.... yeah, seems off.
[11:40:41] <twnqx> try to encode something with eye resolution with 18bps...
[11:40:46] <hyc> would need massively long persistence to even paint an image
[11:40:53] <hyc> and then you'd have massive ghosting
[11:41:14] <av500> ok, seems I missremember
[11:41:33] <twnqx> A 2006 University of Pennsylvania study calculated the approximate bandwidth of human retinas to be about 8960 kilobits per second, whereas guinea pig retinas transfer at about 875 kilobits.
[11:41:35] <twnqx> :)
[11:42:00] <twnqx> well, that's retina, not eye->brain with prefiltering, though
[11:42:16] <hyc> hmm. so we only 8960kbps on video codecs?
[11:42:42] <av500> twnqx: ok, I was wrong, its 16: http://fm.schmoller.net/2007/03/16_bits_per_sec.html
[11:43:57] <av500> I guess 18 was made up by a journalist who was exagerating :)
[11:44:18] <twnqx> that's weird
[11:44:30] <hyc> eh, the diagram says 10^7 bits/sec input
[11:44:33] <twnqx> but it's talking about consciousness
[11:44:38] <twnqx> not signal processing
[11:44:54] * av500 googles for another seemingly related article
[11:45:04] <av500> :)
[11:45:36] <hyc> and 10^6 for audio. someone must be heavily rounding off; we don't have 10:1 ratio between video and audio streams
[11:45:48] <av500> if its all these high bitrates, how come I dont remember anything about most movies I watched a day ago? :)
[11:45:50] <twnqx> nah, i can accept the number, you just have to define from where to where more precise
[11:46:26] <twnqx> it basically says the brain takes 8mbit/s input from the eyes, and processes them down to extract the few bits that are relevant at the time
[11:46:46] <av500> see, skip the processing and inject information at the relevant level :)
[11:46:55] <twnqx> would be cool
[11:47:09] <hyc> would be ... limited
[11:47:30] <hyc> you can watch a movie a 2nd or 3rd time and see things you didn't notice before
[11:47:36] <av500> like: "it was a movie with kate beckinsale"
[11:48:14] <hyc> so just because the brain will only absorb 16 bits doesn't mean you can get away with only providing 16 bits of info in the source material
[11:48:34] <twnqx> it depends on the purpose.
[11:48:42] <hyc> av500: does that you mean you like Kate, or dislike?
[11:49:34] <pross-au> Hii
[12:53:15] <av500> 4% wrong aspect ratio, is that noticeable?
[12:53:36] <mru> it might be
[12:53:53] <mru> "do I look fat in this aspect ratio?"
[12:53:54] <av500> my non scientific gimp test says no...
[12:54:22] <thresh> mru: there is no good answer to this type of question
[13:07:44] <Tjoppen> interesting.. raw images can be wrapped on a line-by-line basis in MXF
[13:09:36] <_troll_> Tjoppen: that's nothing!
[13:09:45] * _troll_ introduces PIXML
[13:09:49] <_troll_> pixel-level xml
[13:10:24] <_troll_> <pixel><component type="red">5</component>...</pixel>
[13:10:41] <CIA-92> ffmpeg: stefano * r23407 /trunk/doc/ffmpeg-doc.texi:
[13:10:41] <CIA-92> ffmpeg: Merge @chapter Introduction and @chapter Description into a single
[13:10:41] <CIA-92> ffmpeg: section, and make the whole rendered in the man output.
[13:10:41] <CIA-92> ffmpeg: Simplify layout, and make it more consistent with that of the other
[13:10:41] <CIA-92> ffmpeg: man pages. Also I cannot see a good reason for keeping split the two
[13:10:41] <CIA-92> ffmpeg: sections.
[13:10:45] <Tjoppen> I actually have a format that is dangerously close to that. I just need to add an optional xs:hexBinary field for the essence data
[13:10:49] <_troll_> and with xpath you can do MC too
[13:10:56] <av500> "red" is too unspecific!
[13:11:25] <kierank> it also needs a dtd to define what colours are
[13:11:31] <kierank> just for semantic purposes
[13:13:48] <janneg> as long as nobody tries to build displays supporting this pixel format we are safe
[13:14:02] <Tjoppen> well, doing it like <line><pixel red="5" blue="10" green="20"/>...</line> would allow for a compilable schema and not too much RAM usage if using a good unmarshaller
[13:14:35] <_troll_> just zip compress it!
[13:15:23] <Tjoppen> btw, if I read the DPX spec correctly it allows up to eight components, each of which could be anything from the usual R, G, B, Y, .., but also things like depth (Z) or "user defined"
[13:15:51] <Tjoppen> so you could define an image as a kind of translucent 3D surface
[13:15:54] <kierank> "would allow for a compilable schema and not too much RAM usage if using a good unmarshaller" --> tell that to openoffice
[13:16:08] <janneg> what is the alleged advantage of this format? it's xml?
[13:16:23] <Tjoppen> DPX? used when scanning film. it's binary
[13:16:34] <Tjoppen> still between 50-200 MiB per frame though
[13:17:17] <Tjoppen> regarding XML, I see far too many systems using it for which schemas can't be written. OpenCV for one
[13:17:48] <Tjoppen> "hey, let's put data in the tag names - that saves space!"
[13:18:41] <_troll_> <white/><green/><brown3/><palegoldenrodyellow/>
[13:19:00] <Tjoppen> indeed. MXFLib does that with its dictionaries
[13:19:24] <av500> _troll_: <katebeckinsale>
[13:19:50] <Tjoppen> <Foo/><Bar base="Foo"/> instead of <class name="Foo"/><class name="Bar" base="Foo"/> (that latter would be schema-able)
[13:19:59] <_troll_> av500: hmm, what goes between that and </katebeckinsale>?
[13:20:30] <thresh> awful acting, i assume
[13:20:34] <janneg> Tjoppen: I was more wondering about pixel level xml
[13:20:44] <av500> _troll_: I have no idea who she lets that close
[13:21:05] <Tjoppen> god no. that'd hardly be useful
[13:21:54] <Tjoppen> you could do something like <frame format="yuv420p>0123456789ABCDEF</frame> though (hexBinary with attribute), which could be mildly useful for data exchange
[13:22:04] <Tjoppen> s/>/">/
[13:22:08] <_troll_> yuck
[13:22:16] <_troll_> y4m anyone?
[13:22:54] <janneg> well someone must have thought it would be useful or he was just completely insane
[13:23:21] * kshishkov thiks it's the latter in any case and the former as a consequence
[13:23:25] <kshishkov> *thinks
[13:25:23] <_troll_> janneg: I was only trolling...
[13:25:25] <janneg> 'completely insane' -> anything
[13:26:20] <janneg> _troll_: I think you mentioned it before
[13:26:42] <_troll_> it's probably a recycled troll, yes
[13:27:11] <janneg> could be
[13:30:45] <_troll_> http://thread.gmane.org/gmane.linux.kernel/992368
[13:31:12] <_troll_> root of the madness: http://article.gmane.org/gmane.linux.kernel/978789
[13:31:34] <av500> lol
[13:33:53] <janneg> lol "jitter that is more or less constant"
[13:34:20] <av500> lol "jitter related to application-startup"
[13:35:07] <_troll_> "For those who posess religious knowledge, or believe in religious phenomea, lets just say that, if you don't comply to certain religious knowledge, you will be tuning psychovisuals for a spirit, and not a human, and the experience will be suboptimal."
[13:35:11] <_troll_> beat that
[13:35:15] <_troll_> oh, wait..
[13:35:19] <_troll_> "Just like the worshipper of one spirit, say, atheist, includes his preferences in the tuning, so does, for instance the hash-smoker, and that is reflected in his tunings. What one would optimally like, is a spirit-free tuning. No personal preference, but tuned for the universal in us all."
[13:35:34] <thresh> is that from the guy's website?
[13:35:42] <_troll_> from the lkml thread
[13:36:00] <thresh> oh god
[13:36:09] <_troll_> from the website: "Numerous studys show that a refresh rate of 72hz is the maximum discernable to the human eye. It is also shown, that this refresh rate, is the best for avoiding pschovisual disturbance, and headaches. I further tuned this refresh rate to 72.70hz, for minimal psychovisual noise. This is also where the human mind, and senses, register the most information."
[13:36:46] <thresh> i suppose the guy's got too much of hash
[13:36:49] <av500> +1
[13:37:20] <janneg> and the troll even has the chutzpa to write "Any answers related to this post, critisising or wasting my time, will be ignored."
[13:37:38] <merbzt> Numerous studys somehow most often turn out to be 0
[13:38:00] <av500> "... Gnome seems to be a source of jitter itself,..."
[13:38:05] <av500> if it was only jitter....
[13:38:18] <thresh> well you cant argue with that
[13:38:18] <janneg> or 1 with a very lax definition of study
[13:38:53] <janneg> i.e. I tried that and I'm convinced it's better
[14:01:34] <CIA-92> ffmpeg: stefano * r23408 /trunk/doc/texi2pod.pl:
[14:01:34] <CIA-92> ffmpeg: Make texi2pod.pl accept @itemize commands with no following character
[14:01:34] <CIA-92> ffmpeg: or texinfo command for specifying how to generate @item marks, and
[14:01:34] <CIA-92> ffmpeg: make it use by default the mark symbol "*".
[14:01:34] <CIA-92> ffmpeg: This is consistent with texinfo docs:
[14:01:35] <CIA-92> ffmpeg: "If you don't specify a mark command, the default is `@bullet'."
[14:01:36] <CIA-92> ffmpeg: stefano * r23409 /trunk/doc/ffmpeg-doc.texi:
[14:01:36] <CIA-92> ffmpeg: Fix texi2pod.pl rendering of the Tips section by putting each @item
[14:01:37] <CIA-92> ffmpeg: command on its own line, and create a corresponding "TIPS" man page
[14:01:37] <CIA-92> ffmpeg: section.
[14:01:38] <CIA-92> ffmpeg: Note that such section is not displayed, as currently only sections
[14:01:38] <CIA-92> ffmpeg: with pre-defined names are rendered.
[14:03:25] <ChrisWi> can someone verify that libavcodec is compiled without -fPIC. I am not able get it with fPIC.
[14:03:37] <ChrisWi> and hence I can not compile vlc
[14:05:26] <ChrisWi> http://pastie.org/987263
[14:09:39] <CIA-92> ffmpeg: stefano * r23410 /trunk/doc/ffmpeg-doc.texi:
[14:09:39] <CIA-92> ffmpeg: Rename @chapter "Quick Start" to "Examples", for consistency with the
[14:09:39] <CIA-92> ffmpeg: corresponding man page section.
[14:14:48] <BBB> ChrisWi: ?? maybe ask on #ffmpeg instead of here
[14:15:05] <j-b> ChrisWi: or #videolan
[14:17:43] <ChrisWi> BBB, did already
[14:18:13] <ChrisWi> j-b, thanks
[14:36:13] <av500> mru: I have transport!!!!!!!!!!!
[14:36:21] <av500> janneg: ping
[14:37:11] <mru> av500: great
[14:37:46] <janneg> av500: pong
[14:37:48] <av500> I have somebody going there this fri or sat
[14:37:52] <av500> janneg: ^^^^^^^^^^^^
[14:38:21] <janneg> I should be available for pickup in berlin
[14:38:25] <av500> great
[14:38:42] <av500> schoenhauser allee 51
[14:39:02] <av500> janneg: where are u in berlin?
[14:39:22] <janneg> schoeneberg, kleistpark
[14:39:31] <av500> ok
[14:39:39] <av500> I will update you
[15:00:22] <mru> the troll on lkml goes on
[15:02:40] <kshishkov> any new tricks worth borrowing?
[15:04:12] <mru> "Mindless people, who set a value of 4000hz instead of 3956, because they don't believe or lack the skill, to tune a value."
[15:06:05] * janneg wonders why he only uses integer Hz values
[15:07:38] <lu_zero> roundup is back
[15:08:17] <lu_zero> KotH: where you'd like to move it?
[15:10:08] <kshishkov> janneg: http://www.xkcd.com/217/
[15:11:13] <j0sh_> wbs: it was the chunked encoding (more specifically, the prefixed length) that was the problem
[15:12:13] <j0sh_> we will have to fix that, the spec saysto use http/1.0 and chunked encoding is a 1.1 feature
[15:33:12] <wbs> j0sh_: ok, so that's another thing in the http protocol that needs to be changeable
[15:37:21] <j0sh_> yep... but hey, it works now!
[15:37:26] <wbs> great!
[15:37:49] * j0sh_ needs a few nights of curling up with rfcs
[15:38:05] <j0sh_> prob never would have caught that chunked problem
[15:38:08] <wbs> btw, the content-length: 32767 thing, what does the spec say about that - what should the sender do if he needs to send more data than that in the POST?
[15:39:08] <j0sh_> the spec says dss ignores the content-length header, its just therre because POST requires it
[15:41:00] <wbs> hmm, okay.. but what if there's a proxy inbetween, then it perhaps will matter?
[15:41:24] <j0sh_> from the spec: "                                                In practice, the actual value seems to be ignored by proxy
[15:41:27] <j0sh_> servers, so it is possible to send more than this amount of data in the form of RTSP requests
[15:41:30] <j0sh_> "
[15:41:39] <wbs> hmm, weird
[15:42:33] <wbs> but I guess that isn't the biggest of concerns
[15:43:27] <j0sh_> there were similar concerns here: http://blog.flameeyes.eu/2009/10/24/apple-s-http-tunnel-and-new-http-streaming
[15:43:41] <wbs> have you tested it to be working with both feng and dss?
[15:43:54] <j0sh_> only feng, let me fire up dss
[15:44:40] <wbs> ok.. I'll read that one later tonight
[16:26:18] <BBB> j0sh_: oh, yeah, did I mention our http protocol handler is pretty crappy?
[16:26:22] <BBB> j0sh_: thanks for fixing it ;)
[16:31:02] <BBB> Tjoppen: I'm hoping to look at the http stuff you sent me also
[16:31:05] <BBB> i.e. today
[16:31:27] <Tjoppen> \o/
[16:31:35] <j0sh_> heh
[16:31:37] <BBB> </late>
[16:31:45] <j0sh_> does our mov muxer add hinting for dss?
[16:31:55] <BBB> I think martin just added that
[16:31:59] <BBB> so yes
[16:32:21] <BBB> j0sh_: also, for changes to http, it might make sense  that you test it with ffserver, that's a major http user
[16:32:31] <BBB> I'll help you with that later ocne you're ready to submit a patch
[16:32:47] <j0sh_> ok cool
[16:35:05] <Tjoppen> btw, "PUT" is a more correct verb for uploads, since the operation is idempotent
[16:35:59] <Tjoppen> I don't recall what people thought about changing that though. might break things that incorrectly assumes POST
[16:37:28] <CIA-92> ffmpeg: rbultje * r23411 /trunk/libavcodec/iff.c:
[16:37:28] <CIA-92> ffmpeg: Move get_buffer() calls from decode_init() to decode_frame(). Anything else is
[16:37:28] <CIA-92> ffmpeg: unsupported and causes crashes when libavfilter is enabled.
[16:37:28] <CIA-92> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>.
[16:37:52] <Tjoppen> also, url_fclose() might want to return void rather than int, since it shouldn't be able to fail (no implementation returns non-zero anyway)
[16:41:54] <BBB> Tjoppen: I agree, but that's an API change
[16:41:56] <BBB> so not for now :)
[16:42:05] <Tjoppen> yeah
[17:02:17] <Dark_Shikari> mru: is there an arm version of clear_blocks?
[17:02:33] <Dark_Shikari> I'm wondering why that didn't show up on your profile
[17:02:36] <Dark_Shikari> because it did here iirc
[17:09:30] <mru> Dark_Shikari: it doesn't tend to show up
[17:10:18] <Dark_Shikari> it showed up here
[17:10:26] <Dark_Shikari> And it's trivial, so I figure it couldn't hurt.
[17:10:36] <mru> what percentage?
[17:11:15] <mru> and what codec?
[17:12:54] <Dark_Shikari> h263, "memset" is 2.7%.
[17:13:01] <Dark_Shikari> It might be from some other part of the app, but I don't know of any big memsets
[17:20:23] <Dark_Shikari> yup, it seems to be from h263_decoe_mb
[17:20:26] <Dark_Shikari> so it would have to be clear blocks
[17:20:30] <Dark_Shikari> er, clear_block
[17:20:43] <Dark_Shikari> oh, both are used, clear blocks and clear block
[17:22:09] <CIA-92> ffmpeg: mru * r23412 /trunk/libavcodec/arm/ (dsputil_neon.S dsputil_init_neon.c): ARM: NEON clear_block[s]
[17:22:47] <Dark_Shikari> LOL
[17:22:52] <Dark_Shikari> that was fast.
[17:29:57] <BBB> I'm confused as for why gcc couldn't come up with that code itself?
[17:30:06] <mru> BBB: because gcc sucks
[17:30:07] <BBB> or let me restate that
[17:30:11] <BBB> what code did gcc come up with?
[17:30:36] <mru> memset call
[17:31:15] <Dark_Shikari> gcc doesn't know the source is aligned
[17:31:32] <BBB> aha
[17:50:18] <dezodorant> jai: u here?
[18:22:50] <wbs> j0sh_: yes, we can do rtp hinting now. just transcode/remux and add -fflags rtphint
[18:27:56] <j0sh_> wbs: that explains it, i ended up having to use mp4creator
[18:33:24] <wbs> j0sh_: yeah.. in my tests, mp4creator created buggy hint tracks, I've used MP4Box instead, that at least seemed to work
[18:34:34] <j0sh_> ah, but now ffmpeg's works perfectly, right?? :)
[18:36:56] <wbs> as far as I know, yes, and if you know of any problems, let me know so that I can fix them :-)
[18:37:05] <j0sh_> heh alright
[19:03:16] <BBB> lu_zero, wbs: any opinions about issue1978?
[19:03:20] <BBB> can I apply?
[19:04:02] <wbs> BBB: I think it's the correct thing to do, so yes
[19:04:38] <BBB> lu_zero?
[19:09:09] <wbs> j0sh_: rtp hinting adds a few percent of extra overhead in the file, so that's why it isn't enabled by default
[19:11:06] <j0sh_> gotcha
[19:11:52] <j0sh_> btw i broke something (probably trivial/stupid), so i'm working on the http stuff so i dont have to hack all theheaders by hand
[19:12:51] <wbs> ok
[19:36:09] <CIA-92> libswscale: stefano * r31300 /trunk/libswscale/ (utils.c yuv2rgb.c):
[19:36:09] <CIA-92> libswscale: Move internal scale context fields initialization from
[19:36:09] <CIA-92> libswscale: sws_setColorspaceDetails() to ff_yuv2rgb_c_init_tables().
[19:36:09] <CIA-92> libswscale: Allow to factorize duplicated code.
[19:36:09] <CIA-92> libswscale: siretart * r31301 /trunk/ (5 files in 2 dirs):
[19:36:10] <CIA-92> libswscale: deprecate palette8topacked32 in favor of public API functions sws_convertPalette8ToPacked32 and -24
[19:36:11] <CIA-92> libswscale: additionallym deprecate palette8torgb16 and its bgr variant without
[19:36:11] <CIA-92> libswscale: replacement. These functions are not meant to be used by applications.
[19:36:12] <CIA-92> libswscale: Discussed at: http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/109340
[19:50:12] <CIA-92> ffmpeg: michael * r23413 /trunk/libavformat/utils.c: Print an error when MAX_STREAMS is reached.
[19:55:10] <lu_zero> hi
[19:55:26] <mru> lo
[19:57:59] <lu_zero> the patch is ok
[19:58:02] <BBB> lu_zero: ok
[19:58:04] <BBB> will apply
[20:01:23] <CIA-92> ffmpeg: rbultje * r23414 /trunk/libavformat/rtsp.h:
[20:01:23] <CIA-92> ffmpeg: Change default number of channels (used if unspecified in the format desc)
[20:01:23] <CIA-92> ffmpeg: from 2 to 1, which is the actual value used in the spec. Fixes issue1978.
[20:01:23] <CIA-92> ffmpeg: Path by John Wimer <john at god dot vtic dot net>.
[20:05:37] <peloverde> Are the rtmp samples on the wiki still good?
[20:06:28] <CIA-92> ffmpeg: siretart * r23415 /trunk/doc/APIchanges: Add an entry to APIchanges for the addition of sws_convertPalette8ToPacked32 -24
[20:07:07] <wbs> peloverde: some of them were ok a few months ago, but not all of them
[20:07:28] <peloverde> wbs, I just found one that works
[20:10:42] <wbs> okay
[20:14:47] <CIA-92> ffmpeg: siretart * r23416 /branches/0.6/libavcodec/allcodecs.c: disable (native) vorbis encoder for the 0.6 branch
[20:27:00] <CIA-92> ffmpeg: reimar * r23417 /trunk/configure:
[20:27:00] <CIA-92> ffmpeg: Do not check_lib for -lva if vaapi is disabled, having -lva in extralibs
[20:27:00] <CIA-92> ffmpeg: if vaapi is disabled is at best pointless.
[20:46:24] <ramiro> has anyone seen a linker error for iphone regarding ff_imdct_half_neon being referenced from _ff_synth_filter_float_neon? ld64 suggests _ff_imdct_half_neon$non_lazy_ptr. what's this non_lazy_ptr?
[20:47:22] <mru> didn't I fix that one?
[20:53:18] <Yuvi> mru: http://pastie.org/988110
[20:53:38] <Dark_Shikari> mru: I found a way to make decoding much faster on our ipad
[20:53:53] <Dark_Shikari> I just spent 2 hours going through the mpegvideo decoder... and butchered it completely
[20:53:57] <ramiro> does the iphone/ipad have a hardware h264 decoder?
[20:54:01] <Dark_Shikari> aka removing about 80% of the code =p
[20:54:01] <mru> Yuvi: I thought I'd done that already...
[20:54:09] <mru> maybe I'm confusing it with another one
[20:54:11] <Dark_Shikari> ramiro: we can't use it
[20:54:22] <Dark_Shikari> so we're moving to Sorenson FLV1 for now
[20:54:39] <mru> what did you do?
[20:54:52] <Dark_Shikari> I saved about 800-1000 clocks per mb on my core i7
[20:54:53] <ramiro> Dark_Shikari: hm, why can't you use it? apple doesn't let us?
[20:55:01] <Dark_Shikari> ramiro: they haven't answered us yet
[20:55:05] <Dark_Shikari> mru: http://pastebin.com/972CxbrV ;)
[20:55:13] <Dark_Shikari> 1) remove all cases that aren't used (qpel, etc, etc) to get rid of extra ifs
[20:55:20] <mru> tl;dr
[20:55:22] <Dark_Shikari> 2) optimize decode_block by hardcoding most stuff, like "last"
[20:55:31] <Dark_Shikari> e.g. things which are normally initialized per-codec, I moved into code
[20:55:46] <Dark_Shikari> Basically this is how fast it could be if the entire thing was templated 5 billion times for every possible h263 variant.
[20:55:49] <ramiro> Yuvi: thanks
[20:55:56] <ramiro> mru: apparently you missed a spot =)
[20:56:03] <mru> Dark_Shikari: how much faster did it get?
[20:56:25] <Dark_Shikari> decode_block went from about 1705 -> 1234 cycles
[20:56:32] <Dark_Shikari> then I cut a hundred more off h263 mb decode
[20:56:41] <Dark_Shikari> then I cut 200 or so off mpv_decode_mb
[20:56:43] <mru> that doesn't answer the question
[20:56:49] <mru> in total, how much faster?
[20:57:00] <Dark_Shikari> I think the total number of clocks before was about 4000 per mb.  it should be about 3000 now.
[20:57:08] <Dark_Shikari> I didn't test a timer of the whole thing.
[20:57:11] <mru> but how much per fucking frame?
[20:57:19] <Dark_Shikari> That would be 25% less time you bozo.
[20:57:42] <mru> there's stuff that isn't done per mb too
[20:57:48] <Dark_Shikari> nothing significant.
[20:57:53] <Dark_Shikari> there's no loopfilter
[20:58:10] <Dark_Shikari> I'm not counting stuff outside of lavc (e.g. texture copying, etc)
[20:59:29] <Dark_Shikari> also, flv is _staggeringly_ crappy
[20:59:35] <Dark_Shikari> it doesn't even have DC prediction
[20:59:37] <Dark_Shikari> not even for INTRA blocks
[20:59:51] <Dark_Shikari> every single intra block has an 8-bit DC code
[20:59:53] <CIA-92> ffmpeg: conrad * r23418 /trunk/libavcodec/arm/synth_filter_neon.S: arm neon: Add missing mangle to external symbol
[21:01:04] <Dark_Shikari> here is my new mpv_decode_mb: http://pastebin.org/299549
[21:01:11] <Dark_Shikari> Can we have all the decoding functions be this simple? :)
[21:19:33] <Dark_Shikari> mru: isn't there a risk to using absolute struct offsets in asm files for huge structs, like in mpegvideo_neon.s?
[21:19:52] <mru> do you have a better idea?
[21:20:46] <Dark_Shikari> I would pass it as a function argument
[21:20:53] <mru> how would you do that?
[21:20:54] <Dark_Shikari> e.g. calculate nCoeffs outside of the function
[21:20:58] <Dark_Shikari> and pass that as an argument
[21:21:00] <mru> gcc sucks at that
[21:21:01] <Dark_Shikari> pass the dc scale as an argument
[21:21:11] <Dark_Shikari> sucks at what
[21:21:19] <mru> the first half of the function
[21:21:25] <Dark_Shikari> also, I'd do DC quant outside the asm
[21:21:27] <Dark_Shikari> it's messy and ugly
[21:21:31] <mru> it spends as much time there as the entire neon loop
[21:21:35] <Dark_Shikari> o.0 what the fuck
[21:21:44] <mru> it branches like mad
[21:21:53] <mru> and schedules like an idiot
[21:21:53] <Dark_Shikari> That's largely the fault of the code
[21:22:05] <Dark_Shikari> some of the branches are totally needless
[21:23:21] <Dark_Shikari> but for example, in x264, as I pointed you the deblock strenght I wrote earlier
[21:23:24] <Dark_Shikari> instead of
[21:23:27] <Dark_Shikari> h->loopf.deblock_strength( h->mb.cache.non_zero_count, h->mb.cache.ref, h->mb.cache.mv
[21:23:31] <Dark_Shikari> h->loopf.deblock_strength( h
[21:23:47] <Dark_Shikari> on x86_64 it's no slower (you have to load them anyways), on x86_32 it's slower but fuck x86_32.
[21:23:58] <Dark_Shikari> And that avoids your gigantic mega-offsets.
[21:25:45] <Dark_Shikari> HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAH
[21:25:50] <Dark_Shikari> Intel copied x264's SATD
[21:25:58] <Dark_Shikari> they copied our asm in the latest IPP
[21:26:09] <mru> legal?
[21:26:14] <Dark_Shikari> Well, they converted it to intrinsics
[21:26:20] <mru> lol
[21:26:22] <Dark_Shikari> But the algorithm is absolutely identical
[21:26:31] <Dark_Shikari> down to the exact munging and horizontal multiply tricks
[21:26:53] <Dark_Shikari> I don't think it's something we can technically go _after_ them for, since we do the same thing
[21:27:00] <Dark_Shikari> But it's a funny form of flattery.
[21:32:56] <Tjoppen> :)
[21:36:49] <BBB> Dark_Shikari: yes you can go after them for it, assuming it's non-trivial of course
[21:37:23] <BBB> Dark_Shikari: and assuming it's gpl-incompl of course
[21:37:55] <Dark_Shikari> it's proprietary
[21:38:03] <BBB> sue the f out of them
[21:38:07] <Dark_Shikari> I wouldn't go after them, that would be stupid
[21:38:11] <Dark_Shikari> because I do the same thing
[21:38:13] <Dark_Shikari> I read other peoples' asm
[21:38:16] <Dark_Shikari> understand the algorithm
[21:38:17] <Dark_Shikari> and copy it
[21:38:29] <Dark_Shikari> Though this is a bit more blatant than I've ever done.
[21:38:36] <BBB> sell them one of your funny proprietary licenses then
[21:38:39] <Dark_Shikari> lol
[21:38:45] <Dark_Shikari> we could actually do that =p
[21:38:46] <BBB> are you the (c) holder of that particular piece of code?
[21:38:48] <Dark_Shikari> Holger is
[21:38:59] <Dark_Shikari> He's signed the contrib agreement though or whatever
[21:39:05] <Dark_Shikari> but either way, I don't want any legal anything
[21:39:07] <Dark_Shikari> I just want them to give credit
[21:39:09] <BBB> go make money :)
[21:39:52] <BBB> I should analyze that asm myself, post it on my blog and slashdot it ;)
[21:40:30] <BBB> and then add some embarassingly overstated title like "Intel steals x264 algorhitms"
[21:40:35] <Dark_Shikari> lol
[21:40:37] <Dark_Shikari> come on
[21:40:41] <Dark_Shikari> that's stupid =p
[21:40:45] <BBB> or better yet, "Intel steals GPL"
[21:40:50] <ohsix> channel is publicly logged eh
[21:40:51] <mru> lol
[21:41:24] <BBB> ok, ok, I won't :)
[21:41:33] <Dark_Shikari> anyways, I don't think that copying someone's algorithm is a copyright violation
[21:41:37] <Dark_Shikari> you can't copyright ideas.
[21:41:45] <Dark_Shikari> But it's good form to give credit for them.
[21:41:55] <mru> but where do you draw the line?
[21:42:12] <iive> algorithms are covered by patents
[21:43:55] <BBB> if the asm calls are identical, it's definitely copyright
[21:44:04] <BBB> if it's more blurry, then it isn't
[21:44:16] <BBB> but yeah, I don't know where the line is
[21:44:30] <kierank> yet sflc to deal with it
[21:44:32] <kierank> get*
[21:44:43] <Dark_Shikari> BBB: they rewrote it as intrinsics
[21:44:54] <BBB> kierank: it's not ffmpeg code
[21:46:41] <iive> Dark_Shikari: is that library newer than x264 code?
[21:47:28] <Dark_Shikari> yes
[21:48:36] <BBB> I'd go contact them, just so you have a good contact point if you want a donation in the future ;)
[21:49:33] <Dark_Shikari> should I embarass them first?
[21:50:02] <kierank> threaten to do so
[21:50:07] <kierank> use it as a bargaining chip
[21:50:37] <Dark_Shikari> lol
[21:50:40] <Dark_Shikari> come on, I'm not evil
[21:51:41] <kierank> they won't accept that it's holger's code
[21:51:59] <Dark_Shikari> ?
[21:52:03] <Dark_Shikari> what do you mean
[21:52:19] <Dark_Shikari> you mean they'll claim its their own?  well of course
[21:52:26] <kierank> just like they won't accept that icc compiled executables are slower on amd
[21:52:56] <Dark_Shikari> lol
[21:53:02] <Dark_Shikari> no, they stated that such a thing is correct
[21:53:08] <Dark_Shikari> More specifically
[21:53:13] <Dark_Shikari> they say that they only have CPU detection for intel chips
[21:53:21] <Dark_Shikari> thus any vectorized SSE2 code or whatever won't run on AMD chips
[21:53:31] <Dark_Shikari> (they also only have timings/etc for intel chips)
[21:53:47] <hyc> I guess timings are believable
[21:54:12] <hyc> but the fact they implemented cpu feature detection bits in the first place trashes the cpu detection argument
[21:54:32] <Dark_Shikari> http://pastebin.org/299677 ok, here's the draft of the post
[21:54:34] <Dark_Shikari> any comments/etc?
[22:02:22] <spaam> nice
[22:03:56] <iive> Dark_Shikari: you know, saying you've been on hunt for optimization ideas is not the best way to start when your goal is to complain that somebody hunted one of your sheep.
[22:04:11] <iive> one of yours.
[22:04:39] <Dark_Shikari> Oh, apparently holger does want to dual license his code to intel
[22:04:42] <Dark_Shikari> So I won't be posting this.
[22:09:17] <BBB> you shouldn't blog about it
[22:09:27] <BBB> you should email the legal people at intel
[22:09:34] <BBB> or the coders, if you know them :)
[22:16:02] <scaphilo> hi all is anyone here who does oprofile ffmpeg? Dark_Shikari told me to do that shortly ;-) Well i think it takes a little bit more than 5 min. has anyone written a script to profile ffmpeg?
[22:17:11] <Dark_Shikari> script?
[22:17:17] <Dark_Shikari> just start oprofile, run ffmpeg, stop oprofile, dump results
[22:18:22] <scaphilo> for the results, i only get the result of ffmpeg as a whole program then
[22:18:42] <Dark_Shikari> you need to use ffmpeg_g not ffmpeg
[22:18:48] <scaphilo> oh i see
[22:18:48] <Dark_Shikari> and do opreport -l ffmpeg_g
[22:19:17] <scaphilo> ah ok wil try that thx
[22:19:36] <Dark_Shikari> btw, mru, any chance you could consider doing deblock_strength for arm?
[22:19:44] <Dark_Shikari> now that we have a C version and you can test it inside x264
[22:21:54] <scaphilo> oh what good that your here do you have an idea what kind of problem i could have when i dont make the fcode mpeg4 not the same like in mpeg2
[22:22:17] <Dark_Shikari> fcode is just a way of storing mv data
[22:22:18] <scaphilo> i fixed it to 4 but im not sure if that leads to some problems with other videos than i currently test
[22:22:24] <Dark_Shikari> it's not a problem if you change it
[22:22:28] <Dark_Shikari> it's still the same dat
[22:22:29] <Dark_Shikari> *data
[22:22:32] <Dark_Shikari> even if stored differently
[22:23:05] <scaphilo> ah ok thx same for the b_code of cause
[22:23:32] <scaphilo> i still have some errors in b frames i thought perhaps that comes from this codes but
[22:23:48] <scaphilo> i think i did something wrog in the mb_type mapping then
[22:24:56] <scaphilo> by the way where the hell do you come from dark_shikari your all the time on :-)
[22:25:57] <hyc> hm, ffplay doc on http://ffmpeg.org/ffplay-doc.html is out of date, it lists -rtp_tcp option but there is none
[22:26:28] <hyc> instead you can append a URL option to the URL "?tcp"
[22:26:45] <hyc> is there a doc anywhere collecting URL/proto-specific options like this?
[22:39:39] <scaphilo> YEAH thats so cool :-) Thank you very much Dark_Shikari oprofiling is really a nice way to do it
[22:40:01] <scaphilo> and takes not more than 5 min
[22:40:22] <Dark_Shikari> Pastebin the results when you're done
[22:41:33] <scaphilo> http://dpaste.com/202060/
[22:41:56] <scaphilo> dont know why this  dct_quantize_c still takes that much time
[22:42:00] <Dark_Shikari> Why is dct_quantize_c even running?
[22:42:08] <Dark_Shikari> That shouldn't run in a trasncode.
[22:42:12] <Dark_Shikari> Nor should dct_unquantize
[22:42:21] <scaphilo> i have to do the quantising because the qscale is not really the same in mpeg2 and mpeg4
[22:42:27] <Dark_Shikari> Then make it the same
[22:42:35] <Dark_Shikari> mpeg4 has an mpeg2-style quant mode
[22:42:39] <Dark_Shikari> Use that instead of h263-style
[22:42:54] <scaphilo> not possible because mpeg4 uses this dquant not only qscale
[22:43:00] <Honoome> tonight I can be quite satisfied with myself… I got feng to work with IPv6 _finally_ after months it wasn't possible to use it at all +_+
[22:43:06] <scaphilo> oh am ok
[22:43:09] <Dark_Shikari> scaphilo: huh?
[22:43:29] <Dark_Shikari> scaphilo: if you have to requantize, your algorithm WILL NOT WORK
[22:43:33] <Dark_Shikari> thus you have to do it without requantizing.
[22:43:46] <Dark_Shikari> And yes it's possible to do.
[22:44:29] <scaphilo> hmm but how do i enable this mpeg2-style quant mode
[22:45:02] <Dark_Shikari> it's just a header bit afaik
[22:45:32] <Dark_Shikari> yup
[22:45:33] <Dark_Shikari> s->mpeg_quant
[22:45:41] <Dark_Shikari> s->mpeg_quant= avctx->mpeg_quant;
[22:45:43] <scaphilo> ah dam is it really that easy :-(
[22:45:47] <Dark_Shikari> it's just a parameter.
[22:46:22] <scaphilo> ill try that thx for your help
[22:46:37] <scaphilo> if you want you will of cause get a version of this oltranscoder
[22:46:46] <scaphilo> when its findished
[22:49:41] <scaphilo> btw:if you have to requantize, your algorithm WILL NOT WORK thats a bit hard. Of cause it works but there is an error you get (not that big if you have small new quant errors) but anyway ill better do what you said
[23:03:44] <mchinen> can someone tell me why is AVFormatContext's data_offset sometimes the end of the file?
[23:04:03] <mchinen> I'm trying to find the first packet.  Maybe there's a better way?