[20:47:05] <@amz> you can't really decode video at 0.0%
[20:47:13] <@amz> for SOME reason, mplayer seems to report cpu usage very wrong
[20:47:15] <@amz> on both windows and linux
[20:47:26] <@amz> unless it's doing it all on GPU
[20:47:29] <@amz> which I kinda doubt
[20:47:43] <Civil> amz, with mplayer it ate around 1-2% (becouse vo=xv use GPU for everything it could)
[20:48:35] <Civil> mplayer now eate 4% of CPU and 2.3% of memory (~25MB)
[20:48:36] <@jfs> unless you have a true 10 ghz c2d i doubt you can decode any reasonable video at 1-2% cpu
[20:48:49] <@jfs> (and similar fast memory and i/o)
[20:49:04] <Civil> jfs, GPU can help a lot...
[20:49:21] <@jfs> ffmpeg doesn't have GPU decoding afaik
[20:49:25] <Civil> if the video isn't in x264 - it realy took a little of resource to deocde.
[20:49:35] * Zephyr (WinNT@Rizon-131C7595.dc.dc.cox.net) has joined #aegisub
[20:49:45] <@amz> even 640x480 xvid takes 20-30% CPU at least for me
[20:49:46] <@amz> on my XP 2200+
[20:50:00] <perchr> my AMD Athlon X2 4600+ uses about 10% when playing back a h264 .mkv from KAA, when using mplayer (on Gentoo Linux)
[20:50:20] <perchr> at least that's what gkrellm reports
[20:50:21] <@amz> here
[20:50:27] <Civil> amz, on my PDA (pxa 270) 512x384 video eate 100% of CPU becouse it haven't got hardware acceleration
[20:50:29] <@amz> 30-40% for afk's Lucky Star 01
[20:50:37] <@amz> on mplayer
[20:50:41] <Civil> perchr, on my A64 4000+ it use around 60% (reported by top )
[20:50:54] <Civil> x264 1080i
[20:51:02] <Civil> but divx 1080p - uses around 10-15%
[20:51:13] * apih (007@saya.seorang.insan.biasa) has joined #aegisub
[20:51:40] <@jfs> points is, you can't get just 1-2% cpu usage playing back any video, unless it's low res uncompressed video that resides entire in RAM and is rendered with GPU acceleration
[20:51:55] <Civil> amz, same AFK's Lucky Star (but 8-th episode)
[20:51:55] <@jfs> (ie. rendered as a textured 3d surface)
[20:52:19] <Civil> top says it that mplayer use 1% of CPU and X use 3%.
[20:52:36] <@jfs> then linux is broken
[20:52:41] <@amz> what's your GLOBAL CPU usage?
[20:52:49] <@amz> like I've said, mplayer is known for reporting wrong usage for whatever reason
[20:52:53] <Civil> amz, 6.6% user, 1.3% sys
[20:53:20] <Civil> 2% eate firefox , around 1% used by xchat
[20:53:23] <Civil> other - mplayer+X
[20:53:44] <@amz> I have a 6600, which even supports PureVideo, and I can't even play Manabi Straight in mplayer
[20:53:55] <@amz> (neither linux nor windows)
[20:54:53] <Civil> amz, Linux's support of purevideo isn't compleat - it can't use hardware for decoding x264 and wmv9 (as I remeber)
[20:55:11] <@jfs> hmm right, mpc using ffdshow for decoding uses 5-10% cpu here playing back afk lucky star 1
[20:55:14] <emptyeighty> isn't Purevideo a DirectShow filter??
[20:55:40] <@jfs> that is, actually 10-20% cpu
[20:56:24] <@amz> emptyeighty: I'm saying that the GPU supports what it takes
[20:56:29] <Civil> jfs, your and mine 10% maybe different :)
[20:56:32] <Civil> can be :0
[20:57:20] <@jfs> dual opteron 2.2 here
[20:57:45] <Civil> jfs, single core a64 2.4Ghz.
[20:57:58] <@amz> well
[20:58:12] <@amz> at any rate, Aegisub's video playback is suboptimal, especially on unix
[20:58:15] <@amz> it's reasonable on windows
[20:58:25] <emptyeighty> nvidia's site says purevideo is "a plug-in for Microsoft® Windows® Media Player and Media Center Edition"
[20:58:36] <@amz> emptyeighty, I'm not contesting that
[20:58:45] <Civil> yeah... even with -vo=vesa mplayer is faster then aegisub :)
[20:58:52] <@amz> I'm just saying that if my GPU supports purevideo, then it has to support everything required for GPU-side decoding of MPEG4 ASP
[20:59:07] <emptyeighty> amz: referring to Civil
[20:59:37] <Civil> emptyeighty, http://www.nvidia.com/page/purevideo.html
[21:00:44] <Civil> emptyeighty, in fact it is ability of GPU to decode h264, wmv, mpeg2, etc. It needs support of videodriver (ATi has something similar to it) and support of vo used by videoplayer... Nothig more.
[21:00:52] <emptyeighty> Civil: where on that page does it say anything about OS?
[21:01:20] <NeSuKuN> on mac, aegisub's video playback sux
[21:01:22] <NeSuKuN> xDDDDD
[21:01:36] <@jfs> isn't vo = video output
[21:01:36] <NeSuKuN> it's even better on a VM
[21:01:38] <@jfs> the output driver
[21:01:42] <@jfs> not the decoder
[21:02:06] <Civil> emptyeighty, nowhere. But it is fact, that mplayer can't use hardware acceleration for playing wmv9 and h264 (at least on Linux)
[21:02:07] * ^Alchemist^ (~UPP@Rizon-69F41878.dd.ronus.pl) Quit (Quit: Storm. <UPP>)
[21:02:23] <emptyeighty> so it doesn't use PureVideo at all
[21:02:27] <emptyeighty> and it can't on any OS
[21:02:36] <Civil> emptyeighty, but divx use it.
[21:02:59] <emptyeighty> DShow divx you mean?
[21:03:27] <@amz> in before TheFluff and "aegisub is not a video player"
[21:03:42] <Civil> ffodivx decoder can Use HW acceleration at least
[21:03:55] <emptyeighty> where do you get that from?
[21:04:15] <Civil> emptyeighty, compare -vo=vesa and -vo=xv
[21:04:32] <Civil> 1-st - CPU usage around 40-50% at 640x480 (100% at 1280x1024)
[21:04:41] <Civil> 2-nd - 5-10% at any resolution
[21:04:51] <@jfs> hmm, xv is overlay i think
[21:05:06] <NeSuKuN> want me to insert an EULA in OSX installation ?
[21:05:08] <Civil> and vo=x11, vo=gl, vo=gl2
[21:05:27] <Civil> xv = XVideo Output
[21:05:45] <@jfs> yeah, XVideo is an overlay surface, i'm pretty sure
[21:05:50] <@jfs> nothing magical there
[21:06:39] <Civil> jfs, but X server use something to accelerate it (if driver with 3d support is installed)
[21:06:41] <emptyeighty> yup, that's not speeding up decoding at all. just a faster renderer.
[21:06:52] <@jfs> Civil yes...
[21:06:57] <Civil> if you use driver nv - it use a lot of CPU.
[21:07:14] <@jfs> overlay video is an accelerated means of displaying fast updating images in a limited region of the display
[21:08:02] <@jfs> it works as a secondary framebuffer on the video card, which is composed together with the main image during the actual video output on the graphics card
[21:08:07] <@jfs> by using a kind of bluescreen technique
[21:08:28] <@jfs> (all areas on the main screen image with a specific colour are replaced with the appropriate part of the overlay surface)
[21:09:17] <@jfs> since the overlay surface can also be in a different colour space/encoding (eg. YUV or YV12) colourspace conversions can be moved from software to hardware
[21:09:47] <@jfs> but those colourspace conversions are the closest you get to decoding acceleration with overlay
[21:10:15] * apih (007@saya.seorang.insan.biasa) has left #aegisub
[21:11:43] <Civil> jfs, videocard can accelerate decoding of some video. ffmpeg use it for decoding of some videos. Mpeg-1, Mpeg-2, and if video card supports - divx/xvid. But no hw acceleration of wmv9 and h264
[21:13:04] <@jfs> this is still the first time i hear about ffmpeg supporting any kind of hardware decoding
[21:13:05] <NeSuKuN> amz: do you want an EULA on OSX installation?
[21:14:04] <emptyeighty> that is becaues ffmpeg doesn't
[21:14:11] <emptyeighty> *because
[21:14:13] <Kamine> ffmpeg only supports mpeg2 hardware decoding through xvmc
[21:14:13] <Kamine> not mpeg4
[21:14:26] <@jfs> NeSuKuN, don't bother about that yet...
[21:14:48] <@jfs> also remember that while we write that the aegisub source is under BSD license (well it is) all aegisub binaries are under GPL
[21:15:19] <@jfs> (hmm though, remind me what gpl libraries we link with again...)
[21:15:24] <@jfs> (always link with)
[21:15:29] * martino (~martino2k@hopeless.romantic) has joined #aegisub
[21:15:56] <@amz> well, dunno about ALWAYS, but... ffmpeg, avisynth (but it has that exception), vsfilter, maybe hunspell
[21:16:01] * Lord- (~Lord@Rizon-2BA26E89.pool.tvnet.hu) has joined #aegisub