On 5/30/07, leon zadorin <[email protected]<mailto:[email protected]>> wrote:
"videos"? How many streams are you receiving on that machine? I though
it was only 1 :-) Generally speaking, it would be best to start
testing with only 1 stream... then if things don't work with more
streams - we will be able to "narrow" things down a little :-)
Oh, there were 2 total. The second one was just an idle h261 stream from
when I was trying 2 instances of vic on the same machine. I'm not testing that
anymore.
yeah... in fact all of the things you describe (e.g. "freezing") is
very like the "underpowered machine" behaviour... but in such cases
the "freezing" is not really "freezing", just vic working on existing
data (frame assembly, decoding and rendering) and not being able to
complete things in time... so all of the "window redrawing", user
key/mouse input get queued by the X server, but not processed by the
application... The only thing is... the "top" output would/should list
vic or Xorg running at close to 100% and the leonlog2 file which you
have emailed to me earlier appeared to list vic only using a small
fraction of CPU resources... and Swap appears not to be used...
Just to clarify a little detail - when you were generating leonlog2
file - was vic running at a time and trying to process video streams
(i.e. was it started with the IP/PORT address on which there was a DV
video stream transmitted from another machine)?
Yeah, it was attempting to receive a DV stream. I can receive h261 and the
like perfectly fine. The lack of CPU usage does seem strange, and I have
replicated it (see below)
Just to be sure:
1) On the machine that is working for you - start streaming a DV stream.
1,1) Generally speaking, whet testing, start with only 1 stream being
transmitted on a given multicast address - if it works - you can
always start adding more video streams later on.
2) On the machine which freezes vic:
2.1) Open 2 terminal windows
2.2) In one of the terminal windows start "top"
2.3) In another run vic... (for testing curiosity, try with the
following switches):
2.3.1) ./vic IP/PORT
2.3.2) ./vic -g IP/PORT
2.3.3) ./vic -g -x IP/PORT
2.3.4) ./vic -g -x -i IP/PORT
2.3.5) run ./vic without any command line options to see what those
switches do and what other new options have been added to vic...
2.4) whilst executing any of the 2.3.1 to 2.3.4 steps - have look at
the "top" output (from step 2.2) and see how much idle system time it
is reporting (with may be how much CPU vic and Xorg are using)...
2.3.1) ./vic IP/PORT: main window doesn't render or respond to input, like
before. CPU usage is interesting... when I do something that should cause the
window to update (like mouseover a button), vic's CPU usage shoots up to 10-20%
and Xorg's goes up a few. This lasts a couple seconds then goes back to normal
(normal being around 90% idle and vic & Xorg using <1%)
2.3.2) ./vic -g IP/PORT: main window still mostly unresponsive - sometimes I
can get the video window to pop up but it doesn't render frames from the
stream, it's just gray. Without the video open, vic and Xorg use about 40% CPU
apiece, and if the video window is open, it's more like 80%/5% for vic & Xorg
respectively.
..and before I could do the rest of these tests our sending machine's video
card just apparently died. If anyone has a somewhat reliable/on
most-of-the-time DV stream (sending over UQ vic of course) available so I could
do more thorough testing that would be great.
If you feel like it - email me your xorg.conf ... also, which linux
are you using (distro, kernel version [uname -a])... ?
xorg.conf is attached. I'm running Ubuntu Linux 6.10 (edgy) with kernel
version 2.6.17-11-generic.
--Andrew
xorg.conf
Description: xorg.conf
