[FFmpeg-devel-irc] IRC log for 2010-08-22

[irc at mansr.com]

[08:31:46] <xxthink> Is VDPAU open source?
[08:34:59] <thresh> libvdpau is
[08:39:36] <xxthink> I download it from http://cgit.freedesktop.org/~aplattner/libvdpau
[08:39:46] <xxthink> but I can't find the GPU source
[08:40:37] <xxthink> is this the right place to download?
[08:41:30] <thresh> GPU source ?
[08:41:54] <xxthink> the decoding source for GPU
[08:42:19] <xxthink> for example, the mpeg-2 decoding source for GPU
[08:43:38] <xxthink> the decoder seems in the NVIDA driver
[08:43:48] <thresh> yes, you need proprietary driver
[08:43:56] <thresh> libvdpau is just an interface
[08:44:01] <xxthink> yes
[08:44:07] <xxthink> I c
[08:44:32] <xxthink> but the driver is not open source :)
[08:46:38] <thresh> of course it is not
[11:53:41] <mru> morning
[11:53:53] <CIA-93> ffmpeg: mru * r24866 /trunk/tests/fate.sh: fate: allow specifying relative path to config file in fate.sh
[12:04:01] <CIA-93> ffmpeg: mru * r24867 /trunk/configure: mmsh depends on http
[13:42:40] <deets> hi all. I know this is the wrong channel for questions about using libav*. However, I'm the only one there currently. So I wonder if it would be ok to ask user questions here as well.
[13:42:55] <deets> there being "#libav-user" of course.
[13:44:28] <kierank> libav-user is a mailing list, not an irc channel
[13:45:32] <deets> argl.
[13:45:33] <deets> sorry
[13:45:45] <deets> I'll switch to the ffmpeg channel
[14:25:48] <CIA-93> ffmpeg: mru * r24868 /trunk/ (Makefile tests/fate2.mak): fate: remove pointless fate/fate2 separation
[14:40:49] <CIA-93> ffmpeg: alexc * r24869 /trunk/libavcodec/x86/ (fft_mmx.asm fft_sse.c):
[14:40:49] <CIA-93> ffmpeg: Convert ff_imdct_half_sse() to yasm.
[14:40:49] <CIA-93> ffmpeg: This is to avoid split asm sections that attempt to preserve some
[14:40:49] <CIA-93> ffmpeg: registers between sections.
[15:08:41] <mru> peloverde: look at that, imdct works on suncc now
[15:11:00] <peloverde> hmm? The only sun config rebuilt so far seems to be gcc3/sunos
[15:12:28] <peloverde> nevermind
[15:12:34] <peloverde> I'm reading fate wrong
[15:17:49] <peloverde> x86_64-w64-mingw32-gcc-4.4 is the machine I really care about at the moment
[15:21:02] <CIA-93> ffmpeg: mru * r24870 /trunk/tests/fate.sh: fate: remove unused variable in fate.sh
[15:48:25] <peloverde> vorbis and aac now pass on win64
[15:48:58] <peloverde> http://fate.mansr.com/x86_64-w64-mingw32-gcc-4.4
[15:53:58] <mru> peloverde: it's fate.ffmpeg.org now
[15:54:10] <mru> though it points at the same thing
[15:54:47] <peloverde> I've never been one to buy into fancy rebrands
[15:56:23] <mru> just saying
[15:56:30] <mru> fate.ffmpeg.org is the official name
[15:56:37] <mru> the other one could go away at any time
[15:56:54] <mru> or turn into goatse
[15:56:57] <mru> you have been warned
[15:57:01] <peloverde> sometimes I still go to mike's fate out of habit
[18:47:15] <BBB> mru: can you give me a ssh account on the win64 box?
[18:47:50] <BBB> or any way in which I could debug
[18:48:24] <kierank> you could use virtualbox
[18:48:31] <kierank> and one of those windows 7 images microsoft provides
[18:48:41] <kierank> not sure if they do win64 though
[18:53:37] <mru> BBB: no, it's not mine
[18:54:31] <BBB> whose is it?
[18:54:41] <BBB> ramiro?
[18:54:45] <mru> probably
[18:55:04] <mru> yes
[19:31:48] <Dark_Shikari> mru: could you try modifying fate to try to track down causes of errors a bit more?
[19:31:52] <Dark_Shikari> like passing different asm flags or whatever?
[19:31:57] <Dark_Shikari> that might be useful
[19:32:18] <mru> no modification necessary, just more configs
[19:33:10] <Dark_Shikari> well I mean localize it a bit more
[19:33:16] <Dark_Shikari> to make it easier to view
[19:33:24] <Dark_Shikari> actually that could be done with gccs too
[19:33:33] <Dark_Shikari> the point is, we could click on a system and get a grid of what fails and what doesn't
[19:33:41] <Dark_Shikari> e.g. "this works with no asm, mmx, mmx2, but not sse2"
[19:33:47] <Dark_Shikari> without having to check a ton of different "systems"
[19:34:16] <mru> I see what you mean
[19:34:34] <mru> but it's hard to present results of ~700 tests concisely
[19:34:38] <Dark_Shikari> I mean, it would be great to have checkasm for ffmpeg
[19:34:47] <mru> patches welcome
[19:34:48] <Dark_Shikari> but I doubt that will happen soon =p
[19:46:08] <BBB> I think for that you don't need more configs
[19:46:12] <BBB> just settable cpu flags
[19:46:15] <BBB> ffmpeg used to have that
[19:46:35] <Dark_Shikari> yeah, what I'd do for that is as follows
[19:46:37] <BBB> e.g. disabling certain flags for mm_support, as in masking them out
[19:46:43] <Dark_Shikari> run each test with many combinations of cflags
[19:46:45] <Dark_Shikari> then add a grid to the test panel
[19:47:02] <BBB> right, that'd be great
[19:47:15] <Dark_Shikari> not as good as checkasm, but something
[19:47:18] <BBB> assuming cflags is my "ffmpeg maskfield", not compiler CFLAGS :-p
[19:47:18] <mru> different cflags => different configs
[19:47:33] <BBB> I mean runtime variable
[19:47:44] <BBB> being able to hardcode mm_support()
[19:47:53] <Dark_Shikari> mru: cpuflags != cflags
[19:47:59] <mru> he said cflags
[19:48:04] <Dark_Shikari> 05:46 <@BBB> just settable cpu flags
[19:48:06] <mru> no, you did
[19:48:10] <Dark_Shikari> er, yeah
[19:48:13] <Dark_Shikari> that was a typo
[19:48:13] <BBB> I think he meant cpuflags
[19:48:22] <mru> makes sense
[19:48:23] <BBB> anyway, great idea, would be very helpful and nice to have
[19:48:29] <Dark_Shikari> mm_support is retarded anyways
[19:48:32] <BBB> not super-urgent, but super-cool :)
[19:48:34] <Dark_Shikari> I mean seriously
[19:48:36] <Dark_Shikari> GLOBAL VARIABLES
[19:48:38] <Dark_Shikari> >_>
[19:48:41] <BBB> haha :-p
[19:48:41] <mru> yes, very
[19:48:50] <Dark_Shikari> And of course, the best part
[19:48:53] <Dark_Shikari> is that despite it being global
[19:48:55] <mru> and that global is only used in one fucking place
[19:48:56] <Dark_Shikari> we treat it as a local var
[19:48:58] <mru> emms()
[19:49:02] <BBB> given that win64 works w/o asm
[19:49:19] <Dark_Shikari> mru: emms should be inlined imo
[19:49:24] <mru> it is
[19:49:27] <BBB> I'll try with different variations of cpuflags
[19:49:30] <Dark_Shikari> I mean, inline inlined
[19:49:30] <BBB> to see which breaks
[19:49:31] <Dark_Shikari> no check
[19:49:36] <mru> if (mm_support & MMX) asm("emms")
[19:49:38] <Dark_Shikari> i.e. "fuck 486 users"
[19:49:47] <mru> I suggested that a while back
[19:49:54] <mru> didn't get quite the buyin I'd hoped for
[19:49:55] <BBB> 486 doesn't exist anymore
[19:49:55] <Dark_Shikari> we do that in x264
[19:50:11] <BBB> mru: I wasn't aware you wanted our approval :-p I'm all for it
[19:50:18] <BBB> under HAVE_MMX if you want
[19:50:18] <Dark_Shikari> I wasn't aware you _needed_ approval, just do it
[19:50:20] <Dark_Shikari> =p
[19:50:24] <BBB> right
[19:50:56] <Dark_Shikari> IMO, if you want to do that, you need to make emms take an argument
[19:51:00] <Dark_Shikari> e.g. a context
[19:51:08] <Dark_Shikari> er, "that" == "what is currently done"
[19:51:09] <mru> why?
[19:51:15] <Dark_Shikari> to avoid a global
[19:51:16] <mru> oh
[19:51:21] <mru> but there's no need for that
[19:51:25] <Dark_Shikari> Yes, I agree, it shouldn't be that way
[19:55:40] <iive> the problem is not that you fuck 486... you also fuck all cpu up to the one I have.
[19:55:52] <mru> fuck you then
[19:57:58] <funman> fympeg
[20:00:56] <iive> the correct solution is to allow inlineing of the asm routines when building for specific cpu, and keep the old generic way when you build generic one.
[20:01:32] <mru> in your world
[20:04:12] <iive> well, I'm eager to see real solution that doesn't involve fucking around.
[20:04:42] <mru> --disable-mmx if you don't have it
[20:04:43] <mru> job done
[20:10:04] <BBB> iive: most distros already do it this way
[20:10:16] <BBB> debian (ubuntu), mandriva
[20:10:46] <BBB> in the real world (apple) this is standard anyways
[20:11:22] <BBB> (and that's b/c they are 64-bits already, so they get away with it, but still)
[20:11:37] <mru> apple real... rotfl
[20:11:47] <BBB> bigger market share than all linux combined...
[20:11:59] <mru> by that token windows would be the most real
[20:12:02] <BBB> Dark_Shikari has suggested multiple times to disable all pre-sse2 functions for functions where >=sse2 are available and when building for x86_64
[20:12:10] <BBB> windows is more real
[20:12:17] <BBB> but its dev environment sucks :-p
[20:12:42] <funman> but it runs delphi!
[20:12:43] <peloverde> I would wager more videos get processed by FFmpeg on linux at places like youtube and vimeo than an all apple systems combined
[20:13:29] <BBB> peloverde: "ffmpeg" is what?
[20:13:43] <BBB> I tend to think of "ffmpeg" as things like VLC, Chrome etc.
[20:13:54] <BBB> I certainly don't use "./ffmpeg" much myself
[20:14:34] <peloverde> even then I think it's the case
[20:14:45] <funman> ./ffmpeg is nice imo
[20:14:45] <peloverde> most youtube video is consumbed by flash on windows
[20:15:01] * pJok uses ./ffmpeg a lot
[20:19:14] <iive> BBB: my distro still builds against i486. Indeed it uses -mcpu=i686.
[20:19:59] <BBB> well of course it does, otherwise it wouldn't run on your cpu if I understand correctly :-p
[20:20:19] <BBB> so by mere logic, you wouldn't use "your distribution" if it didn't build that way, because it wouldn't run on your cpu
[20:20:41] <iive> BBB: my cpu is not THAT old.
[20:20:42] * BBB wonders why configure hangs on win64
[20:20:58] <mru> BBB: does it hang or just take insanely long time?
[20:21:12] <BBB> I wouldn't be able to tell the difference really
[20:21:21] <BBB> is there a debug mode?
[20:21:23] <BBB> ./configure -d?
[20:21:27] <BBB> so it tells me what it's doing
[20:22:10] <iive> bash -x ./configure
[20:23:52] <mru> wtf @ h263dec.c:556
[20:25:50] <BBB> uh
[20:25:55] <BBB> it was indeed not hanging :-p
[20:25:57] <BBB> that's kinda funny
[20:26:04] <BBB> ok gotta run now
[22:00:39] <kierank> What is this code trying to acheive on a signed value? http://pastebin.org/733592
[22:02:59] <roxfan> it toggles ebx high bits
[22:03:11] <roxfan> hard to say what for without seeing the rest
[22:04:37] <kierank> I know it does that. It's part of gain adaptive quantisation
[22:04:48] <kierank> the rest of the code multiplies by the inverse gain element
[22:11:01] <twice11> kierank: Could that code possible be used for sign-extension of a value already determined to be negative? ebx would be the number of "missing" bits.
[22:11:16] <twice11> i.e. EBX=3 for a 29 bit value.
[22:11:47] <kierank> that sounds correct
[22:12:00] <kierank> and makes sense considering the context
[22:15:13] <mru> where does the code come from?
[22:16:17] <kierank> dolby e's gaq decoder
[23:38:49] <BBB> has anyone ever noticed that windows, or maybe this is cygwin, is really quite slow?
[23:40:19] <Dark_Shikari> cygwin is very slow
[23:40:22] <Dark_Shikari> configure takes about 5 minutes
[23:40:25] <Dark_Shikari> this is because fork() is slow on windows
[23:40:52] <Compn> cygwin is ungodly slow
[23:53:30] <BBB> can't someone fix windows?
[23:53:39] <BBB> I mean, even my mac is 10x faster than this wincrapbox
[23:53:45] <BBB> excusez-le-mot
[23:54:33] <lu_zero> BBB: fix how?
[23:55:00] <lu_zero> windows is an apparently nifty idea implemented in a not so good way
[23:55:12] <lu_zero> the idea is bad and so is the rest =P
[23:55:50] * lu_zero tries tmux now