[vlc] CPU utilization, colors and streaming

[Alexander Isacson]

Hi all.

I'm using VLC to remote control a small robot I’ve been building. The
situation looks as follows:

I have bought a Spectra 8 card (http://www.ituner.com/spectra.htm) capable
of capturing 4 simultaneous streams. I'm using three of those on my robot.
Two of them are fixed B/W cameras and the last one is a colour
pan-tilt-zoom camera. I'm sending these streams over WLAN to my computer
using these two commands:

vlc -vvvvv -I rc v4l:/dev/video0:norm=pal:size=400x300
v4l:/dev/video1:norm=pal:size=400x300
v4l:/dev/video2:norm=pal:size=400x300 --sout
'#transcode{vcodec=mp4v,vb2000}:std{access=udp,mux=ts,url=operator:1234}'

vlc -vvvvv -I rc v4l:/dev/video0:norm=pal:size=200x150
v4l:/dev/video1:norm=pal:size=200x150
v4l:/dev/video2:norm=pal:size=200x150 --sout
'#transcode{vcodec=mp4v,vb2000}:std{access=udp,mux=ts,url=operator:1235}'

It all works and I can pick up the two streams on my computer. The problem
is that the colors are not captured correctly. As described on in my email
to this list on Nov 7 red looks blue and blue looks red. Except for that
everything works and the utilization is about 70-75% to encode and stream
the 400x300 stream and about 20-25% to encode and stream the 200x150
stream.
It is possible to have both streams read from either /dev/videoX at the
same time and I get identical images on the computer. Here are some
interesting lines in the vlc output:

[00000143] v4l input debug: v4l device uses frame size: 360000
[00000143] v4l input debug: v4l device uses chroma: RV24
[00000143] v4l input debug: added new video es RV24 400x300
[00000144] packetizer_copy decoder debug: Running copy packetizer (fcc=RV24)
[00000146] stream_out_transcode private debug: creating video transcoding
from fcc=`RV24' to fcc=`mp4v'
[00000143] main input debug: 3067 loops consuming user: 392, system: 101
[00000143] main input debug: ES 0x1, stream 0x1, fourcc `RV24', selected
[OK:0/ERR:0]
[00000144] main decoder debug: killing decoder for 0x1, fourcc `RV24', 10
PES in FIFO

In order to remedy the colour problem I followed the suggestions in the
reply to my last mail and installed xawtv. After running "streamer -d -o
pic.jpeg -c /dev/video1" I ran vlc again. Now the colours are correct and
CPU utilization is down to 40-50% for the big stream! A significant
improvement! The problem now is that I cannot have both streams read from
the same device, /dev/video1 at the same time. On one stream it seems that
only every other line is updated a few times a second (really choppy) and
on the other stream the picture is all dark green. Here are the same lines
from the vlc output.

[00000143] v4l input debug: v4l device uses frame size: 180000
[00000143] v4l input debug: v4l device uses chroma: I420
[00000143] v4l input debug: added new video es I420 400x300
[00000144] packetizer_copy decoder debug: Running copy packetizer (fcc=I420)
[00000146] stream_out_transcode private debug: creating video transcoding
from fcc=`I420' to fcc=`mp4v'
[00000143] main input debug: 1197 loops consuming user: 329, system: 120
[00000143] main input debug: ES 0x1, stream 0x1, fourcc `I420', selected
[OK:0/ERR:0]
[00000144] main decoder debug: killing decoder for 0x1, fourcc `I420', 11
PES in FIFO

I'v read about the video formats in v4l(2) and looked at the documentation
for the bttv driver. How do I change the v4l output format? Can it be done
from within vlc? Can I use v4l-conf? I would like to try every output
format to see which one works and how much CPU vlc uses to encode it. Once
I've ran "streamer" I can't get the old colour format back without
removing the bttv module for the kernel and inserting it again.

The complete output from dmesg after inserting bttv, the output from vlc
before and after running "streamer" and the output from streamer are
available here: http://isacson.dyndns.info/media/v4l-debug/

If any other information is needed to resolve this, I'll be more than
happy to try an provide it.

Thanks in advance!

Regards
/Alexander Isacson

-- 
This is the vlc mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/support/lists.html
If you are in trouble, please contact <postmaster at videolan.org>