[vlc-devel] VIA xvideo bug?
Dermot McGahon
dermot at dspsrv.com
Fri Sep 24 12:29:13 CEST 2004
Hi,
I'm testing multicast to a VIA ME1000 board using vlc as player.
CPU: IDT/Centaur/VIA C3 Nehemiah (Family: 6, Stepping: 5)
xvinfo shows:
[root at epia root]# xvinfo
X-Video Extension version 2.2
screen #0
Adaptor #0: "NV10 Video Overlay"
I was a little surprised by this, thinking that NV10 was something
nvidia specific. The xvinfo output is similar to what I see on a
desktop machine with an nvidia graphics card. The graphics chipset
is VIA CLE266 Unichrome.
Kernel is 2.6.5, Xorg 6.7 and the "via" module is loaded by X.
[root at epia root]# uname -a
Linux epia 2.6.5-1.358 #1 Sat May 8 09:04:50 EDT 2004 i686 i686 i386
GNU/Linux
[root at epia root]# grep "Release" /var/log/Xorg.0.log
Release Date: 18 December 2003
X Protocol Version 11, Revision 0, Release 6.7
[root at epia root]# grep via /etc/X11/xorg.conf
Driver "via"
[root at epia root]# grep via /var/log/Xorg.0.log
(II) LoadModule: "via"
(II) Loading /usr/X11R6/lib/modules/drivers/via_drv.o
(II) Module via: vendor="X.Org Foundation"
(II) via: driver for VIA chipsets: CLE266, KM400, K8M800
[drm] failed to load kernel module "via"
I hope the [drm] message is not causing a problem. I've just noticed
that and will look into it.
On this cpu, playing back PAL MPEG2 TS @ ~8mb/s causes between 50-60%
of cpu to be used, but the bug, if it is one, is that Settings->Extended
GUI->enable, causes the cpu usage to shoot up to about 93%. What exactly
does enabling this setting do?
On a desktop machine with a PIII-800 and nvidia graphics, this does
not happen: although cpu usage is high (60-80%) even without enabling
the extended gui.
Extract from top, before ticking the enable box in the extended gui
screen:
top - 09:31:04 up 16:49, 5 users, load average: 3.09, 2.89, 1.73
Tasks: 75 total, 2 running, 73 sleeping, 0 stopped, 0 zombie
Cpu(s): 64.4% us, 5.9% sy, 1.3% ni, 26.8% id, 0.0% wa, 1.6% hi, 0.0%
si
Mem: 224600k total, 215600k used, 9000k free, 25280k buffers
Swap: 457844k total, 0k used, 457844k free, 59664k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2306 root 15 0 62888 22m 47m S 18.1 10.4 22:51.31 X
3390 root 15 0 27780 14m 20m S 3.9 6.4 0:12.18 gnome-terminal
2546 root 25 10 33796 19m 22m R 1.3 9.0 0:49.82 rhn-applet-gui
3499 root 16 0 2840 904 1620 S 0.7 0.4 0:03.29 top
2438 root 15 0 14800 7512 11m S 0.3 3.3 0:02.65 metacity
2544 root 16 0 13628 4244 11m S 0.3 1.9 0:00.16 pam-panel-icon
and after:
top - 09:30:31 up 16:48, 5 users, load average: 3.14, 2.85, 1.67
Tasks: 75 total, 4 running, 71 sleeping, 0 stopped, 0 zombie
Cpu(s): 91.1% us, 6.9% sy, 0.3% ni, 0.3% id, 0.0% wa, 1.3% hi, 0.0%
si
Mem: 224600k total, 220400k used, 4200k free, 25240k buffers
Swap: 457844k total, 0k used, 457844k free, 61040k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2306 root 16 0 62824 23m 47m R 13.6 10.7 22:45.84 X
3390 root 15 0 27736 13m 20m S 7.5 6.4 0:11.11 gnome-terminal
2438 root 15 0 14800 7512 11m S 0.6 3.3 0:02.47 metacity
2530 root 16 0 26376 16m 18m S 0.3 7.3 0:07.03 gnome-panel
2538 root 16 0 18964 6216 16m S 0.3 2.8 0:00.27 magicdev
The extra cpu usage does not seem to be accounted for anywhere!
Another strange thing that does not seem right, is that I can't seem
to get top and ps aux to match up. ps aux seem to suggest much lower
cpu usage figures than top does, for the X and vlc processes at least.
[root at epia root]# ps aux | egrep "X|vlc"
root 2306 2.2 10.6 62824 23972 ? S Sep23 22:35
/usr/X11R6/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7
root 3454 0.4 12.6 158172 28480 pts/0 S 09:19 0:02 vlc
--extraintf rc --fullscreen udp://@239.192.160.4:5000
udp://@239.192.162.4:5000 udp://@239.192.163.4:5000 --udp-caching=1000 -vvv
I started looking into this when we noticed that the picture became
"jumpy" after extended periods of playback. This is only when the
extended gui is enabled. VLC is rock solid playing back multicast at
cpu usage levels of ~60%. We have let it run for three days and it
has performed very well.
These are the messages output during "jumpy" (93%+ CPU) playback and
are probably no surprise given the CPU usage:
[00000251] main private debug: decoded 56/108 pictures
[00000250] main video output warning: late picture skipped (32417)
[00000249] main video output warning: late picture skipped (67857)
[00000249] main video output warning: late picture skipped (38659)
[00000249] main video output warning: late picture skipped (15706)
[00000249] main video output warning: late picture skipped (-9452)
[00000250] main video output warning: late picture skipped (31801)
[00000249] main video output warning: late picture skipped (86631)
[00000249] main video output warning: late picture skipped (6716)
[00000251] main private debug: decoded 90/108 pictures
[00000249] main video output warning: late picture skipped (-15438)
[00000250] main video output warning: late picture skipped (1327)
[00000251] main private debug: decoded 92/108 pictures
[00000250] main video output warning: late picture skipped (33394)
[00000249] main video output warning: late picture skipped (9272)
[00000249] main video output warning: late picture skipped (43081)
[00000249] main video output warning: late picture skipped (36718)
[00000249] main video output warning: late picture skipped (83956)
[00000250] main video output warning: late picture skipped (114041)
[00000249] main video output warning: late picture skipped (19023)
[00000249] main video output warning: late picture skipped (57168)
[00000250] main video output warning: late picture skipped (10354)
[00000250] main video output warning: late picture skipped (103324)
[00000250] main video output warning: late picture skipped (225365)
Ideally, we would like to get CPU usage down to 10% or lower, by
utilising the Unichrome driver (unichrome.sf.net) and an xxmc video
out - xxmc is the unichrome projects extension to xvmc which provides
for VLC level decoding i.e full mpeg decode in h/w, not just motion
compensation and IDCT.
But, for the moment, it would be nice to be able to use s/w decode.
We can. We just can't control the brightness from the extended gui
at the same time!
Is this a known bug? Any more information I should supply?
Dermot.
--
--
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel
mailing list