So the other day I wanted to hook up an old projector I’d gotten my hands on a while back to my MythTV box in a dual-screen (TwinView) configuration. So I duly plugged it in. Nothing happened. Updated the drivers (Ubuntu 10.10) through the hardware drivers panel, and while my normal monitor was fine, the projector wouldn’t allow a resolution greater than 640×480. Annoying.

Fortunately, I could trace this down to the EDID data from the projector being dodgy (or something along the way causing problems- the cable is a dodgy thing from China, so that’s a potential culprit). Basically, nVidia’s drivers don’t let you ignore EDID data, even with the NoEDID option in xorg.conf.

So what you end up having to do is actually pretty simple- basically, take the EDID from a working monitor and apply it to the broken display in xorg.conf. Dump the edid.bin through nvidia-settings, the GUI utility, and copy it up to /etc/X11/edid.bin.

Then you just edit your xorg.conf like so:

# This monitor is our dodgy one.
Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "CRT-0"
    HorizSync       28.0 - 33.0
    VertRefresh     43.0 - 72.0
    Option         "DPMS"
    # Note the option below.
    Option "CustomEDID" "CRT-0:/etc/X11/edid.bin"
    Option "PreferredMode" "1024x768"
#    Option "NoEDID" "True"
# This doesn't work! Ignore it.
EndSection
# This monitor works with default EDID from the monitor.
Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "Samsung SyncMaster"
    HorizSync       63.6 - 63.6
    VertRefresh     60.0
EndSection

And bam, you’ve got a working display! As I understand it, this will limit you to the resolutions in the EDID file, but if the monitors are a match or similar, this should work.

Finding out about this trick saved me many, many hours of fiddling about with xorg.conf, so I hope you too find this useful.

So when I moved in to my current university digs, the previous tenants had left a few things behind. Notably, they’d had Sky. So we had a Sky box in the living room and a dish on the wall. In the UK, if you want fast internet these days, you need Virgin Media. VM gives you cable TV in the bundle, so I didn’t want to pay for Sky. But Freesat’s got some nice stuff on it, including BBC HD and that sort of thing. So how about we get ourselves some free TV?

Now, Sky uses the same satellite for the UK as a lot of Freesat stuff. So ignore the dish- all you need is to leave that bit alone, and make sure that you’ve got a cable from the dish LNB to somewhere you can put your PC. Where it’s pointed is probably 28.2 East, which has a bunch of appropriate satellites.

What you then need is a capture card. DVB-S is the standard for satellite, though DVB-S2 is used for some HD encoding (specifically, BBC HD is now on DVB-S2). DVB-T is for terrestrial stuff, and comes in on coax from a standard TV aerial – you can get combo cards, which will let you pull down extra stuff if you’ve got the coax feed. Stuff from your LNB typically comes on F-type cables/connectors, down 75 ohm cable. I have yet to find a decent UK supplier for patch or extension leads – if you know one, let me know.

The LinuxTV wiki maintains a huge list of hardware compatibility with Linux and capture cards, so check there before you go buy anything. I got a Compro S350 card, which works great for DVB-S – I’ve also ordered a Technisat S2 HD card, which should do DVB-S2, and I’m going to look out for a DVB-T card.

Now, we need to tie all this together next. So we need some software and a PC. The PC wants to be a decent spec – I’m using a Pentium 4 box with 768MB of RAM as my server, which is on the low end of things. A faster machine would be better, obviously, but it’s all I have to hand. I stuck a decent (GeForce 6600) graphics card in there, too. Fast CPU is the priority, really- we’re talking high definition decoding, encoding, transcoding and playback. If you’re on a budget, look into Intel quad-core chips (Q6600s, that sort of thing). Intel is the way to go wherever possible. If you’re doing this properly, high-end i7 would be my choice- that or a Xeon or similar. 6-12 core chips would be just the ticket. High-end (newer 8800 series and above) nVidia cards support VPDAU, which lets you offload video decoding and processing to the GPU.

The software to use is MythTV. I’m using a standard Ubuntu 10.04/11.04 (‘Classic’ mode on 11.04) install, and then installing MythTV atop that. On the server, just install the mythtv, mythtv-themes, xmltv and mythweb packages. On any other clients you can install the mythtv-frontend package, and optionally the mythtv-themes package. The client-server model of MythTV means you can combine backends and frontends to build your system. It’s crazy powerful in terms of flexibility. But the short story is, you can have a very nice TV system in very little configuration.

See this excellent guide for more information on how to set up MythTV with Freesat. Basically you just need to tune it in to the right satellite and set up the input properly so it’ll get the channel list. MythTV’s config options take some getting used to, but it’s eminently doable. And once you’ve gotten everything talking, you have a -very- capable system.

So, well done to the MythTV team. One hell of a package, that’s for sure. And Linux DVRs are now in my mind far, far more capable than any other potential choice for DVRs. With MythWeb, I essentially have my own private little iPlayer- but for every single bit of Freesat’s programming. What’s not to like?

So, you might figure that’s a problem. You’d be, partly, right. Video involves a lot more data, loads more numbers to crunch as a result, more bandwidth, and so on. Not to mention the relevant methods of capture are immensely more expensive to implement than the equivalent-quality audio. I’d like, though, to highlight a few nice things for open source video and production.

For any broadcast worthy of the description, we want to be able to do this:

• Work with multiple camera feeds both close to and further from the computer
• Fade between cameras
• Overlay static graphics
• Overlay dynamic text
• Add decent-quality audio
• Stream to as wide an audience as possible

So let’s start with cameras. Cameras are expensive. Buying handicam type consumer-grade things won’t cut the mustard as far as I am aware. I don’t know enough to speak on the subject of HDMI capture (which things like the Blackmagic Studio can do, purportedly to Linux), but that’s the only output format those cameras present. Firewire/IEEE1394 remains a popular format of direct capture in Linux. In broadcast, SDI and HD-SDI are now the main format for video/audio transport, and affordable (I say affordable- low-end professional cameras, ~£3,500 on eBay) cameras support it as a standard and again, Blackmagic cards and other capture devices are available with Linux support. HD/SD-SDI are in my mind the ideal format to be working with because as a transport protocol it is capable of long cable runs- meaning your cameras can roam around or be placed where it most makes sense from a camerawork perspective. You pay extra, but compared to any other capture format it makes loads of sense. PC capture cards are not particularly expensive – a few hundred pounds gets you a card with SDI I/O and balanced audio I/O and analogue video I/O thrown in, too. Stick that in a PCI-E capable box and you’re good!

This brings me to topic two – CPU power. Specify the fastest box you can. Right now I’m testing an encoding-and-compositing-on-one-box setup, and with no cameras connected I’m at 80% CPU usage on a 2.8Ghz Core 2 Duo. This stuff needs brains. Intel i7 processors are the way to go right now, or high to mid end Xeons. RAM, too- at least 4 gigabytes, more wouldn’t hurt at all, especially if you use videos in your composites. Aim to keep all your data in RAM, or use an SSD. Multiple computers with gigabit networking will let you split loads across machines, as I’ll talk about in a bit.

Now so far we’ve spent a lot on cameras and computers. Fortunately, that’s all you need (audio equipment aside). Now we get everything in as a source in Linux, we can do the fun stuff- compositing our graphics and videos and text on top of the cameras, switching between them, and then broadcasting.

Composition we have a lot of choice in. We can use freej, which I am very interested in but have been unable to get working properly on Ubuntu so far. Or, we can use WebcamStudio. It’s a fairly flexible package that lets you do compositing of lots of source types, arranging things into layouts. So we might have an intro layout that has placeholder graphics describing the stream for while we’re setting up the cameras. Then we might have a couple of layouts that have our camera feeds on them. For a test setup I wrote a small Python script to get the last few tweets from our on-campus media, then told WCS to run that command and put the output on the screen as a rolling text item. Now we’ve got our video cameras with contributions from news teams overlaid. We’re starting to look professional!

Audio is a piece of cake. All we need to do is capture it and encode it with the video. The former is too complex to detail here but needless to say you end up bringing in your final mixdown of audio into a soundcard input which you can then bring into my next chunk of software for the post – Flumotion.

Flumotion is really neat. It lets you build GStreamer chains very easily to do broadcasting, and has a lot of added functionality on top of that like test chains, and crucially the ability to split tasks across computers fairly seamlessly. You can make your rig a network of 3 machines, put video compositing on one, capture on another, and combining and encoding of those streams can be delegated to another machine- for instance. There’s loads of ways to work with this. Another way I’ve thought about doing things would be to encode using Driac or another high-res HD codec the feed from each camera on a local Icecast server or HTTP server, then pull that compressed feed down into the compositor, then do the lossy for-broadcast encoding prior to distribution. This has the benefit that you can also write the Driac encoded data direct to disk, giving you clean-feeds of each camera input for later editing and production use. Perfect!

So, how about streaming? Well, turns out this is pretty simple. We use Flumotion to generate a Theora/Vorbis encoded Ogg container, throw it at Icecast2 using the shout2 module, and then use HTML5 video tags with a fallback on the Cortado Java player to embed it into pages. This works without any plugin requirements on most modern browsers, and will seamlessly fall back to Java if HTML5/Theora/Vorbis support is lacking. Perfect! Icecast2 gives us failover and relay options for expansion and redundancy for free, and doesn’t need much in the way of resources. The fact that we can push to this means that we can site this outside any networks we might be using, and we don’t have to worry about firewalls at the venue so much as long as we can send out to our remote host.

The main issue here is in making everything realtime. With video, that’s expensive. I reckon for a two-camera setup including buying computers and ancillary equipment we’re talking somewhere around £10,000 to £15,000 setup costs. But that’s actually pretty good – considering what it gets you. You’re now a real, bona-fide online TV station capable of real time coverage- something very few places can boast. For student media that’s a massive boon to both the people running the media and students involved with it, as they can now learn what amounts to the most stressful and complex aspects of TV broadcast production in a fairly safe setting, and for students consuming the media it means much better coverage, more engaging events and more fun in general.

This is a very exciting time for student media, where there is a lot of room for experimentation and improvement to try and provide the absolute best in a safe, controlled environment. Of course, student media means student budgets, but TV is rapidly becoming affordable, and is certainly within the grasp of any SU in the country who wish to go down this path.