DVD Studio Pro

Hal

Each year at ultralab we have embarked on a digital creativity project with young people. This year we went worldwide and invited children to make short videos and animations. Some of this has subsequently appeared on BBC2 (more on that another time), and all of it goes onto a DVD which we author at the ‘lab.

This is always a tremendously intensive time for us. This year, Matt did the video editing, Neil did the sound work, Alex did the graphic design and I put the discs together (with lots of help again from Matt… and Alex).

One of the features we wanted was a video jukebox, where a viewer could select any clip in any order and build a play list. We restricted it to eight clips, but it was a fairly complex bit of scripting that achieved this for us. Huge, huge thanks to Alex Blanc for working through the maths involved and entertaining the idea that ‘bit-shifting’ in 16 bit registers was do-able! Previously I have only seen this feature done theoretically and only with eight clips available as a maximum. We had twenty four clips to select from…

Of course, inspiration has to arrive from somewhere, and in my case it came from Alex Alexzander who is based over in LA. Our contact via the various DVD forums on the web has grown over the last year or so, and it was he who first suggested it could be done, and wrote an article and shared sample scripts to get it all going. Thanks Alex!

To cut a long story short, the viewer can select a single clip, or keep going until eight are chosen. Playback will then commence and when done return you to the jukebox menu. This involved a script for filling the registers with the selected clip numbers, a script to clear some of the registers to use in the next bit, a script to extract the clip numbers from the registers in sequence, a script to control which clip played and a script to clear all of the registers ready to start again. The register stuffing and unstuffing were the two biggest scripts – they started off as a massive 40 line each job – Alex brilliantly reduced them to just about nine lines. If ever I get a chance, I’ll post them, and add a tutorial so that you can apply them yourself. You’ll need two menus, a shedload of chapters on a track for your DVD and the ability to think through the logic of where these scripts take you. Other than that, any project you do can use these methods!

Thanks again to Alex, Matt and Neil – let’s hope the tapes we sent to replication come back with fully working discs!

PHP

Hal

Blimey… and there was I thinking I didn’t have time to stop to learn a scripting langauge! How wrong can you be.

Well, it isn’t really about having time is it? It’s all about purpose and whether or not the need is there which drives the desire to learn. In my case it is, since I am part of a team working on a project with the Design Council and the site makes use of PHP (and Flash – but that’s a whole other story for later).

I’m still trying to make sense of it, but thanks to yet another colleague I am beginning to understand it a little bit more. Unlike any other formal learning, where a chunk at a time is taken, tried, repeated, applied, etc, I am having to dive into the deep end and see the entire thing holistically. It’s like reading a book but only knowing a fraction of the words, yet trying to understand the story… tough call.

So, many thanks to Alex for his tireless explanations, loan of books and the like – and big apologies to all who are having to suffer my expletive driven learning style!

Final Cut Pro ‘discoveries’

Hal

OK – not a real discovery as such – probably well documented elsewhere, but we were chuffed to have found it!

The problem was two-fold. First, capturing footage from a camera needed a pre-set to match the camera. More often than not the sound would be out of sync by the time we got it onto the timeline. Secondly, putting the footage onto the timeline often meant we had to render it before we could edit it. Sigh.

First one was easy-ish. We simply had to understand that the camera was set to capture sound at 32Khz instead of the expected 48Khz. Making a capture preset based on 32Khz sound cured that one (of course, the camera is capable of 48Khz sound, and that will be the first thing I look into on Monday).

The second was a little more tricky. Looking at the footage, some of it went onto the timeline without the need to render, and some didn’t. There was obviously something different between the formats – and yet they all came from DV cams.

Looking more closely, we found that some of the footage was in DV PAL format, and some in DVCPRO PAL format. What on earth is the difference? Doing a little digging around (isn’t the Internet a brilliant thing?) I found this table to explain it. So how did we solve it…?

In the end it was simple – we figured out that the timeline really showed a graphical view of the sequence that we created… so we had to check the sequence pre-sets. What we found was that FCP creates sequences with different formats of DV, and where we imported footage that needed rendering, the sequence we put it into was a different format to the captured file. Easy, innit?

We just changed the sequence to match the file, lo and behold, the red render bars disappeared and off we went!

In fact we could save ourselves a lot of trouble by looking in the asset bin – the formats of the clips are all listed! We should have read the manual, shouldn’t we?

Anyway, Matt has been doing the editing, I’ve been concentrating on the encoding – we are both learning and that’s no bad thing!

Interlace, deinterlace

Hal

Well… here we are at the beginning of a new DVD for Ultralab and Matt and I were trying to find a way to present the footage from all of the summer schools. What we found was that there was a lot of interlacing showing on the films when viewed on a computer.

What the heck is interlacing? It is a good question – and I don’t have a good answer except to say that TV pictures are made up of two ‘fields’ which appear on alternate lines. The TV set shows the first field and then the second, fast enough so that our eyes can’t see the change (although on some older TVs the change is noticeable as a ‘flicker’). On a computer screen, there is no such thing – it shows you the complete picture, but what happens when you show interlaced footage from a camera onto a computer? For the most part it looks OK, but where there is sudden movement the computer shows the first field and then the second field out of sync. Typically this looks like there is a row of ‘mouse teeth’ along the edges of the image and in really bad cases (such as in fast motion) the computer can display a striped ‘ghost’ of a person or object in two places at once. On a TV those ghosts simply look like subtle blurs and the interlacing never shows up.

So how do we deal with this – the DVD will be projected from a computer at the main ‘launch party’ in December, and it is quite likely that it will be viewed more on a computer than a TV, but of course not exclusively. We therefore had to find a way to get the best out of both situations.

We decided that one way around it was to de-interlace the footage. This is risky in some ways, depending on how it is done. If you remove a field, then a TV loses a massive amount of the picture resolution, which is no good. If you remove a field and then duplicate the other, overlaying it on top of the first then it is slightly better, but the very best way would be to use an adaptive de-interlacing method which keeps the vertical resolution by subtly blurring the two fields and joining them to be a single picture… this is similar to the way I understand progressive scan pictures are made (but then, what do I know…?)

So we tried it, and it looked pretty good on the computer screens – razor sharp, in fact, rather than with loads of mouse teeth. So we then built a test DVD and tried it on a range of TVs. In all cases the footage was pin sharp and it looked as if we had cracked it.

But this wasn’t the end – being a total perfectionist I needed to understand the interlacing issue even better, and looked to the Los Angeles Final Cut Pro User Group forum, where I asked the question – how does deinterlaced footage look when shown on a TV. The answer I needed came from a very respected Graeme Nattress (Many thanks Graeme).

Graeme explained to me the processes of deinterlacing, the tools available to do it and what to expect – it is akin to going somewhere towards re-creating a film look on video (which in my mind is no bad thing). I promptly went to nattress.com and bought the film look filter set that Graeme has developed and will now be using that with all of the Summer School clips.

The major down side of all this comes when we go to encode the footage to MPEG2. We are fortunate to have a decent enough hardware encoder (Mediapress Pro from Wired Inc) which works in real time from an output on the camera. However, deinterlacing the footage in Final Cut and then printing it back to a tape on a DV camera re-interlaces it.. D’oh! We can’t then use real time hardware encoding unless I can find a way to go to a camera or deck without the interlace. Instead, we have to go for a QuickTime transcode from DV to MPEG2 – the quality is outstanding, but the time… about 5:1 (which is better than the approximate 10:1 we would get through software alone).

More news about encoding as it arrives…

Is there a future to it?

Hal

Here I am, at home on a Friday, wondering what the future might hold.

Nothing unusual about that, of course, except today there was a meeting with the immediate line manager for the workplace, who tried very hard to convince me that he wasn’t here to shut us down.

Trouble is, it sounded just like when Tony Blair gives a message of support to a cabinet colleague, who promptly loses their job a week later.

Gulp. let’s hope it isn’t so…