TonyBlog

Streaming last nights LILUG meeting (see last post) did not go as well as I had hoped for it to go. I guess the main problem was that I had never actually tried it on my laptop - so there was not a trace of gstreamer on the whole dang system… I ended up even having to compile gst-entrans to get it working. I had a nice placeholder looping intro video (a rickroll with some overlayed text) that lasted for most of the meeting streaming from my desktop computer. My laptop wasn’t powerful enough to encode the video in real time at the quality I had it set to, by the time I thought to lower the settings it was already the end of the meeting. The stream at the end of the meeting (of people just sitting and talking) apparently worked very well, varied from 60-100kbit (I believe, according to vlc) and was quite watchable. Next time I’ll borrow someone elses laptop (configured before!) probably, and use that to stream it.. Next meeting should go better. =]

Streaming video has always been a hassle, and still is.

The way I did it today works pretty well.

Using a DV camera over firewire, I was able to pipe the DV stream through ffmpeg2theora and then to the icecast server.

The command ended up being something like
dvgrab - | ffmpeg2theora -v 2 -x 160 -y 128 -f dv -o /dev/stdout - | oggfwd 10.98.98.101 8000 passwordremoved /live.ogg

Ah, but it’s not that simple.
First, getting dvgrab to work.
With debian testing on my laptop, all the apps like dvgrab and kino used raw1394 - but someone decided to remove the raw1394 because something better exists. Eventually, I ended up stealing the kernel from debian stable and I’ve made a note to compile a brand new one with raw1394. It took a while to figure out that dvgrab wasn’t gonna budge and use something other than raw1394.

Next, you’ll notice the quality on that is very, very low. This is because the CPU on my laptop is a Pentium 3-M 1.2GHz, it just can’t keep up. My solution to this is a filthy hack but it works. Sitting on lan a few feet away from my lappy is my desktop, a 2.4GHz Q6600 Core 2 Quad, so I ended up using netcat to pipe the uncompressed DV data through my lan to the listening netcat, waiting on my workstation. This actually works quite well.

On my desktop, I did a derivative of the command mentioned earlier:
nc -l 8080 | ffmpeg2theora -v 2 -x 480 -y 320 -f dv -o /dev/stdout - | oggfwd 10.98.98.101 8000 passwordremoved /live.ogg
Notice the higher resolution video quality - now bandwidth is the reason to scale it down, not CPU power.

Then, after that command, all I had to do on the laptop was
dvgrab - | nc 192.168.2.248 8080

Even though its TCP and hackish, it works.
Sadly (and obviously), this is not usable to stream from a remote location - when you’re away, the CPU you have - is the CPU you’ll use. I sure could use a new lappy…

The good thing about this is, the quality I encoded in my laptop comes out to around the right amount of bandwidth to be streamed over EV-DO to the icecast server. I haven’t tried that but it could mean awesome ogg/theora cellular video streaming with the expected quality.

I recently redid most of the software and a bit of the hardware of my network. The only sad part about this is that a windows box is now part of my network, A laser printer I have (Xerox Workcentre XD100) needs windows to work so I setup a print server on an old mini P3, couldn’t think of a better use for it.

First, IPv6.
My network now all has IPv6 access through 6to4 using 6to4.nro.net
Here is my IPv6 network startup script on my router

ip tunnel add tun6to4 mode sit ttl 64 remote any local 69.113.41.194
ip link set tun6to4 up
ip -6 addr add 2002:4571:29c2::1/16 dev tun6to4
ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1
ip -6 route add 2002:4571:29c2::/48 dev xenbr0
ip -6 route add 2002:4571:29c2:def::/64 dev eth2
echo 0 > /proc/sys/net/ipv6/conf/all/autoconf
echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra
echo 0 > /proc/sys/net/ipv6/conf/all/accept_redirects
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
echo 0 > /proc/sys/net/ipv6/conf/all/router_solicitations

It sets up my IPv6 subnet with the tun6to4 device, then it configures it to route IPv6 to xenbr0, which is my brouter (see later Xen section) and to eth2, which goes to a switch and runs the rest of my lan.
radvd, which allows for stateless autoconfiguration of devices (notably cooler than DHCP, though DHCPv6 is useful on some occasions), is configured to hand out slightly different addresses to my lan and to my Xen VMs.

interface xenbr0 {
AdvLinkMTU 1480;
AdvSendAdvert on;
prefix 2002:4571:29c2:abc::/64
{};
};
interface eth2 {
AdvLinkMTU 1480;
AdvSendAdvert on;
prefix 2002:4571:29c2:def::/64
{};
};

So now my lan gets addresses starting with 2002:4571:29c2:def::, and my Xen machines get addresses starting with 2002:4571:29c2:abc::

I’ve connected with IPv6 to freenode for a while (and my xen machines have unique RDNS so I have a nice tonyb@xen1.tonybox.net hostmask when I connect from my cluenet shell server), and it works quite well.

Now, onward to Xen.
I got bored with the old setup on my machines of Fedora 8 just sitting there, so I decided to install Debian (after trying out a few other distros) on it, and setting up Xen on it. I also upgraded its hardware to be a dual core Pentium D 3.2GHz with 2GB of ram, giving me lots of room to play with VMs (I have 5, with 4 usually running so far and they all run smoothly).

Vector:/etc/ipv6# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1126 2 r----- 8121.9
Vector-Xen0 1 128 1 -b---- 1075.8
Vector-Xen1 2 384 1 -b---- 1980.0
Vector-Xen2 7 256 1 -b---- 78.3
Vector-Xen4 8 128 1 -b---- 82.2

Xen0 is a web server, and an IRC server, Xen1 is a semi-public shell server (see http://cluenet.org/), Xen2 is an LTSP server for my lan, Xen3 was supposed to be an asterisk server but I haven’t gotten around to configuring it yet, and Xen4 is only there because scratchbox doesn’t work on 64bit systems correctly (nothing compiles right) and I didn’t want to mess up something that is useful. This blog is on Vector-Xen0!

The networking setup I have for Xen is kind of odd because every one of Xen’s standard network setups either didn’t allow the VMs to talk to the internet, talk to each other, or killed my lan boxes access to the internet. Eventually I settled for a ‘brouter’ setup as described here, and that has been working nicely, the Xen VMs all have static IPs of 10.98.98.(101+vm number). I dunno why I started with 10.98.98.101 for Xen0 but it works, the VMs can talk to eachother, my lan (192.168.2.1/24), and the internet, and also have IPv6 access.

Finally, printing.
I have a very old Xerox WorkCentre XD100 photocopier/printer, it works very well but it has no drivers for linux/unix and doesn’t even support postscript. The only way for me to print anything to it was to grab my dad’s windows work laptop and plug it into it. Eventually, I gave up trying to setup a linux print server for it and put windows on an old box I found (it had an OEM windows 2000 sticker on it so …). This still did not work because with windows print sharing, both the client and the server need drivers specific to that printer, the most I could print from my linux box was gibberish (and once it printed out the 30-something page source to a postscript test page and refused to stop). Using ghostscript, gsview, a tool called RedMon, I set up postscript emulation, and now I can print things again! Setting up CUPS to use a standard LPD network printer was easy once it was a generic postscript printer. If only ReactOS had some kind of printing/network printing support - I dislike having to use windows but at least its contained in a little box next to my printer with no screen and VNC the only way in. I really missed the ability to print things …

Blogging is fun! Last time I did this was summer!

For those of us who are lazy or forgetful, and yet still like their computers locked when they walk away - there is a solution. My computer has a simple, cheap, bluetooth dongle in it - that, teamed with a simple script and a bluetooth-enabled cell phone, makes my comptuer lock itself when I walk away.

Gentoo-wiki has the script and a simple guide relating to it
http://gentoo-wiki.com/TIP_Bluetooth_Proximity_Monitor

The script makes the bluetooth dongle on my computer constantly check if my phone is within range of it, if it finds that it is not in range (I went to the bathroom, etc) - it then tells xscreensaver to lock my system - and when I walk back in, the system quickly unlocks, as the computer see my phone, and unlocks my computer. Simple and quite effective.

I made a simple video of me using a metal case to block the signal and demonstrate what happens when the phone goes out of range.

http://workstation.tonybox.net/stp60505.ogg
Video is OGG/Theora with vorbis audio

Note that the audio is very low volume, using the mic built into my camera..