Having discovered that while everything was working quite well for MPEG content in ‘film mode’, like the feature film on a DVD, I hadn’t really tried things with stuff in interlaced mode. Things like the ‘making of’ programmes on DVDs tend to have been made for television, and contain frames made up of two fields that may have movement between them.

The end result was a horrible juddering, where the fields were sometimes being played in reverse order. Objects that should have moved across the screen smoothly, were actually taking two steps forward and one step back.

For a while now, the power supply has been heating up quite a bit. It seemed as though insufficient air was being pulled through the power supply by its fan.

It turns out the the problem was the positioning of the PSU and its fan relative to the heatsink of the CPU. The fan was positioned exactly level with the heatsink at a distance of about 12mm. Instead of air being sucked into the PSU and out its vents at the other end, I believe this was causing air to circulate between the middle of the fan and the outside of the fan; needless to say, it was getting fairly hot inside there.

Having built a simple serial infra-red receiver compatible with the LIRC project, some time ago, I finally got around to configuring it and testing it in the TVapp. It’s all working nicely with an old Sony remote that was lying around.

In trying to get mplayer to play pause-free, I decided to have a look at VideoLAN. Having perused the main loop in mplayer, while trying to figure out my timing problems, I’d seen that it’s code’s not pretty :-). Looking through the VideoLAN code, and looking at the development documentation shows me that the VideoLAN code is more approachable.

I’ve now got the VideoLAN client (vlc) running on the TVapp, but not without some hassles. The problem stems from a piece of code in the XVideo display driver that waits for three X events before continuing on with initialization; it was only receiving two of the three, and so the driver was blocking forever. For now I’ve hard-coded the window width and height, that the driver needed the info for, but I need to look into that further.

A lot of the problems getting smooth, quality, TV output from the Trident have revolved around the fact that television timing is interlaced. It looks as though no-one has really tried to use the Trident Xv driver in an interlaced mode.

The problems I’ve had are:

• Initially all video was stretched out vertically to twice the correct height. After some digging I found a register bit named MC Interlace Display, that fixed that.

Well it turns out there was another solution to eliminating tearing, while using no extra CPU time.

It turns out that the Trident display controller has built-in anti-tear support. Basically, this amounts to double-buffering where the controller lets you update the pointers to the next page to display, while not actually changing pages until the vertical retrace is in progress. It took quite a bit of messing around to actually get it to work, because the data-sheet was short on details, and somewhat misleading, but I’ve finally got a version of the Trident Xv driver that works tear-free with mplayer.

The essential problem of trying to play a video stream correctly on TV in a tear-free and jump-free way is to synchronize the delivery of new frames with the vertical retrace period; the time around the vertical sync pulse when the monitor is moving the beam from the bottom back to the top of the screen.

So far my attempt at achieving this has been to hack my video card’s X11 XVideo driver to sit in a polling loop until the bit in the video controller registers indicates that retrace is in progress. While this works, it sucks up a lot of CPU time in a busy-waiting loop; time that could have been better spent decoding video and audio streams.

As at 20-Nov-2002:

The first milestone for me, is to be able to sit down and watch through a whole DVD without having any noticable problems. I don’t necessarily need a remote control, or anything fancy, but I need to be able to forget about my creation enough to enjoy the film.

To that end, the current remaining obstacles are:

• the Pioneer DVD is really quite noisy. The DVD-116 seems not to slow down in response to using the hdparm utility with the -E parameter. I downloaded a Pioneer utility for DOS/Windows that is supposed to slow the drive down to quieten it down, but have not yet had a chance to try it out.

In order to keep a track of the progress of the TVapp PVR project, and other stuff, I need a weblog that can help me keep track of, and organize, my thoughts.

I’ve been sitting paralyzed on this one for a couple of months now, trying to work out just the right database model that fits my plans for how I believe it should work. I want some of it to be organized hierarchically, outline style, and other parts to be more like a traditional weblog with small, quick posts. Yet other parts should be fixed, reference, pages that get updated with the latest information every so often. On top of all that I want readable URLs for the whole thing, that people can easily grok to know immediately where they are and where they can go from here.

The software components of the TVapp currently consist of:

• Linux Terminal Server Project for network booting and NFS mounting of all persistent volumes (the TVapp has no hard-disk),

• mplayer for playing the MPEG-2 streams from the server and DVD,

• XFree86 and the Trident CyberBlade driver for video output. I’m currently in the process of patching the Trident driver to correctly handle XVideo overlays in interlaced modes.

Currently planned are:

• Linux Infra-Red Controller for IR control,

The TVapp hardware currently consists of:

• Celeron II 1.1GHz with 64MB RAM,

• MSI MS-6368 motherboard with on-board Trident video and 10/100 LAN,

• Pioneer DVD-116/2 DVD-ROM drive,

• custom VGA-composite PAL converter board,

• 19" rack-mount 2U case,

• AOpen Micro-ATX power supply.

Also planned are:

• Infra-Red receiver for LIRC use,

• Noritake 128x32 graphics vacuum fluorescent display (VFD) for menus and status display,

• several push-buttons to go with the display.