Too busy to blog!

I'm snowed under; long days helping a big facility to move premises. I've tried to take half term off too spend time with Sarah and James (the only boy left at home since his brothers went to Uni last month) but have wound up working two days so far this week - ho hum.

So; here are just a few technical things I had to get off my chest.

• If you use a Blackmagic Ultrastudio Express (I do - it's a a great way of playing out HD/SDi for demo'ing equipment, calibrating monitors and displaying training material) then be aware that the current version of the app/driver (v. 9.8 currently) is very unstable on OS-X 10.9 Mavericks - use the previous version 9.7.8 instead - all here.
• Do you ever need to demo/test DolbyE encoded material - this is the clip I use (from my pals at National Geographic)
• Do you ever need to do audio shuffling within an HD/SDi signal - shuffle, adjust levels, correct phase reversals, delay (up to 2,400mS), maybe apply dynamics? The most effective way I've ever found of doing this is with an AJA HD10AM, a Yamaha 0196V and the MY8AE option card; £2.5k for full control of two audio groups within an SDi stream; You couldn't do that with anything from Bel, Snell & Wilcox, TC Electronic or any other manufacturer of audio processors.
• Hard drives - "MTBF= 30k hrs"; inter-quartile range is where >50% of HD fails occur. A few last 100k hrs, some only 2hrs as I discovered when the replacement cloned hard drive in my media computer failed after a couple of hours of use. Thankfully I'd cloned it twice! Don't trust spinning hard drives. A motto for our age should be "Friends don't let friends use RAID5"!

That's it, Christmas can't come soon enough!

Windows remote desktop for Raspberry Pi

It's not very open-source/Linux but the best remote desktop I've found so far for the Pi is the venerable Windows RDP (Citrix Winframe or whatever else you want to call it). I know you should be able to run an X-server and all would be well but I haven't been able to find a nice combo that works across all my Windows, Mac and Linux boxes; RDP is the only lingua franca.

So - to set it up on the Pi;

1. Start up your Pi to the terminal prompt. 
2. Type the following command "sudo apt-get install xrdp"
3. If promoted enter your password (the default is "raspberry")
4. Type "Y" and press enter.
5. This is now installing xrdp onto your Pi which is the software we are going to use for the remote desktop connection.  Wait for it to complete.
6. Restart your Pi.  We are going to check that xrdp is going to start up automatically.
7. When your Pi has booted to the command prompt look for [ ok ] Starting Remote Desktop Protocol server : xrdp sesman.  This shows you that xrdp is installed and automatically starting up on start up of your Pi

It takes best part of half an hour to extract and install but once running it's the most responsive experience - far better than VNC and even better than Apple remote desktop. Not quite as good as sitting at the machine (or over an Amulet/Teradici network connection) but excellent none the less. 

If you want to get to it via your router or firewall open one port - TCP; 3389.
Client for OS-X, Client for most Linux versions.

An alternative guide from May 2016;
http://www.circuitbasics.com/access-raspberry-pi-desktop-remote-connection/

Avid, KVM systems and the cry of "...not fit for purpose"!

There are several things that happen when you plug a monitor into a graphics card. I'm assuming DVI (this is the 21st century!) and all other displays standards; HDMI, DisplayPort and Thunderbolt all follow a similar principle.

1. Pin 16 on the DVI connector on the graphics card is refereed to as the "hot plug detect" pin and is held logic-high (at +5v) through a very high value resistor. When you attach a monitor the pin is momentarily taken low to alert the graphics card to the fact that a monitor has been connected. 
2. The graphics card generates an interrupt on the PCI-e bus
3. Windows sees this and uses it to generate an EDID exchange request
4. The monitor responds with it's EDID profile
5. If the EDID profile is the same as last time the graphics card driver does nothing; it's the same monitor after all
6. If the EDID is different the driver re-sets the system resolution - this is particularly important if it's either a lower resolution or frame rate than it was running at before; if it didn't do this you'd get black screens. Nobody wants that.

Now then, Avid Media Composer does something different! It listens for the interrupt and when it sees it it halts operation and displays an error message saying it needs to re-start. Even if all that has happened is that your monitor cable has fallen out of the back of the computer and you've reconnected it - go figure.

The upshot of this is that when you're using a KVM routing solution of any kind and you assign a new pair of monitors to the Avid it insists on re-starting. I've been aware of this for a while and I let people know about it when demo'ing or presenting at trade shows; but it's just the way of things. There is nothing you can do whilst Avid does the wrong thing. Amulet - my favorite KVM-over-IP system does exactly the right thing; it holds off asserting pin-16 (and triggering the chain of events above) only when absolutely necessary. A media operator can be switching around four Media Composers and each workstation is unaware that the operator is being promiscuous. Amulet only asserts pin-16 when there really is no other option; when a new desk-end "zero client" takes control of a machine it hasn't yet seen. The only place I've seen this to be a problem so far is when an editor starts a layback to videotape, presses disconnect on his desk-end zero-client and calls his operator saying "...I've started the layback, I'm off home; can you watch it through to the end?". Then, the operator tries to acquire that Avid and by necessity the Amulet has to alert the computer to a new pair of monitors and Media Composer halts (ruining the layback).

This was the issue at ITV Salford and I home-brewed a little gadget to stop the Avid being able to tell when new monitors where attached; I essentially neutered it's ability to detect pin-16. 

So, I think Amulet does exactly the right thing, if it didn't you'd loose the ability for workstations to detect what monitors were attached and pretty soon you'd have rooms where you had black screens; nobody wants that. The bogeymen here are;

• Avid - why on earth doesn't it do what Windows does?
• Editors who don't watch their own laybacks!

We are now in an argument with a customer who I explained this all to when I was demo'ing Amulet, but we didn't win the SI quote, but we still supplied the KVM. The SI who is installing is shouting blue-murder about "...not fit for purpose" and we're having to brew up 150 adaptors to keep everyone sweet. My feeling is this will cause more trouble further down the line just for the ability to not close an Avid project for those occasions when you need to hand a machine off to someone else. What kind of workflow needs that?!

Technologies that made the difference in Television

Will Strauss (writing for Broadcast Magazine) asked me for a couple of ideas for an article he was putting together; you can read it here. My Engineer's Bench collaborator Hugh Waters got in with SMPTE timecode.

The original ideas I sent to him were;

1. The Mostek MK4096 Dynamic RAM chip (and subsequent MK4196 16k DRAM) was the enabling technology that allowed construction of all early digital video devices in the seventies; TBCs, Framestore Synchronisers and Digital Video Effects (ADO, Quantel 5000, Squeeze-Zoom etc) - being dynamic memory these chips required constant refreshing but the nature of video is that the store is constantly being read to make the next line or frame of video. The chips were fast enough that once multiplexed in banks of (typically eight) video pixels at around 75nS clock could be stored. Without DRAM there would have been no picture-in-picture, no timebase correction, no standards conversion, no digital video effects and no digiscan telecines.
2. The Discrete Cosine Transform - as a mathematical technique for transforming pixels into frequency distributions the DCT doesn't actually provide any reduction in data for digital TV signals but it does then allow all manner of compression to take place. MPEG2 in the nineties allowed DVD, Transmission servers and DVB-T and DVB-S powering the first wave of standard-definition digital television. In the noughties MPEG4 and later variants (H.264, AVC etc) allowed HD pictures to be compressed to data rates unthought-of previously. Most contemporary video compression starts with the DCT.
3. Pixel and even frame-free video(!) - this will be the enabling technology of the next decade that will usher in ultra-high-definition TV. Prof Phil Willis of Bath University is pioneering work that will make video a descriptive object technology rather than pixels, lines and frames. Once divorced from set resolutions and framerates it will be up to the display device to render the vectors, contours and shaders at whatever resolution and framerate the device supports.

Using a DD-WRT router to NAT between two wireless segments

I've mentioned DD-WRT firmware in the past - it's an open-source replacement firmware for lots of cheap domestic internet routers. If the stock firmware on your router isn't doing it for you or you just want to see what all the fuss is about it is a superb way to make your £50 beige plastic router really sing; enterprise level network control for not much effort. It can terminate VPNs, do QOS and lots of the things you'd normally expect from a Cisco business class device.

Not all routers can take a different firmware image, but if yours is based on the Broadcom 54G chipset (an awful lot are) then you're away to the races; otherwise it's £15 on eBay!

Now then, my two eldest boys are away to university this month and it turns out that one of them is going to live in a student house that only has WiFi - I intended that they would both take DD-WRT routers with them to isolate their little dorm-room networks from IT ne'er do wells (NAT - Network Address Translation, the kind you get with a router, is an excellent defense against port-scanners). BUT, without a wired connection to place on the WAN side of the router how do you isolate and provide both wired and wireless connections behind the router's firewall? My first thought was to buy one of those "connect your Sky+ box Ethernet to your WiFi" adapters. It would turn the insecure WiFi into a wired connection that would sit on the WAN side of the router. 

BUT, it's one more thing to go wrong and I was sure that DD-WRT could do it with a bit of tinkering. I looked at a few of the guides online and they were very convoluted with warnings about obscure settings causing trouble and so I decided to figure it out from scratch. It went surprisingly well and now I have a Linksys router that can attach to an existing WiFi access point and then NAT that connection through to another WiFi segment as well as the wired RJ45 links.

So, couple of things to point out.

• My home WiFi's SSID is thorpedale4 and the IP range is 10.100.100.x (.8 is the router)
• I wanted all the hosts on the other side of the Linksys to be on a 192.168.1.x network

First up - I set the Linksys to not be an Access Point but to be a client wireless device (taking baby steps; I just wanted to make sure I could attach it to the house WiFi)

This is done under wireless>basic settings>wireless mode and is set to client and then go to wireless security and make sure you've entered the necessary settings (WPA key etc)

Reboot the router and check it is connecting to the external WiFi - see above. After this make sure you can get out to the internet from a wired connection on the Linksys. At this point the Linksys will be passing back all protocols to the main router and so you'll find the laptop is on the same IP range as the main network and there is no link-isolation (no firewall between the two networks) - we're not there yet!

Next, set the wireless>basic settings>wireless mode to repeater and add in a second virtual wireless interface (this will be your new wireless segment);

Then set up the security - again, the first is for the wireless you're attaching to;

BUT, the second is for the new network you're creating. As the router is now in repeater mode the new wireless segment is on a separate IP subnet (found in the setup>basic settings tab) and by default on the 192.168.1.x segment. The same applies to the wired connections on the Linksys - job done!

Attaching to the new network is as you'd expect;

and looking at the network details shows we're not on the house's 10.100.100.x network;

In fact, trying to reach the new network from the "outer" network;

As far as I can tell there is only one downside to this method - speed; the 54G wireless is now only running around 22Mbits/sec on both segments and that's no surprise as the Linksys is having to hold up two 802.11 links (different frequencies) using only one radio.
BUT, I have a router than can happily attach to a potentially insecure wireless network and produce a new wireless segment as well as wired Ethernet with the SPI (state-full packet inspection) firewall in the way. I paid around a tenner for the router!

PSE detection, interlaced video and VidChecker

I've been preparing some training notes on PSE (hence last week's podcast) but noticed that VidChecker's analysis of a recent BBC recording suggested there were more flash events than were apparent to the eye. Have a look at this Off air MPEG2 from BBC News, 22nd July and pay attention to the timecodes as shown in the analysis in the second screen-grab. 

It looks like I've discovered a bug in VidChecker! The mixes to and from white that seem to provoke the PSE violation are at field rate (as you'd expect from any studio vision mixer) but VidChecker, by necessity, does a frame analysis and so the magic "...no more than 20 Cd/m2" prohibition on frame-frame luminance changes (as measured on a displayed calibrated at 200 Cd/m2 for peak white) are twice as likely to be triggered.

I mentioned this to the guys at VidCheck and this was the response;

Phil

You are right that the first 3 below are fades to white and back again and should not really be picked up as flashing.  

Scott has taken a look at the file, and it appears that the problem is in the interlacing artefacts during the fades where alternate lines are lighter and darker.  He has put in a fix for the next release.

Thanks again for the file and for finding this!  Attached some docs. You may already have them

Regards

Simon

The helpful document they sent was ITU rec 1702 which has a few more pointers than the OFCOM spec I used in the podcast.

Engineer's Bench Podcast - Photosensitive Epilepsy

Phil goes over OFCOM, DPP, Harding and other aspects of PSE.

Find it on iTunes, vanilla RSS, YouTube or the show notes website.