Temporal Dithering; good for colour depth, bad for extending!

I've become quite a fan of products based on Teradici - an on-the-fly compression system that allows dual-DVI w/peripherals to be extended over ethernet. It works very well and you can't tell you're not looking at something that's been packetised and extended over a network. Howver, a fly in this ointment is the current gen ATI graphics drivers on OS-X. They use a technique called Temporal Dithering;

Temporal dithering is a technique employed by some graphics cards to simulate colors that they cannot natively display by rapidly changing the colors of pixels, tricking the eye into seeing “in-between” colors. During PCoIP remote sessions, temporal dithering can cause extremely high bandwidth utilization because the rapidly changing pixels force the PCoIP protocol to constantly deliver large screen updates to the remote desktop.

The upshot of this is that when you have nothing going on screen - no mouse movement etc (where you'd expect to see no data traveling on the network) you get;

And the effect on screen is compression artifacts and a sluggish mouse pointer. The guys at Amulet Hotkey are looking into it for us, but it might be a deal-breaker.

Flailing around the web revealed someone at Disney who has produced tweaks to X's configuration file for use under Linux; unfortunately this doesn't work in OS-X as the dithering is done by the driver. However, just for reference (or the lulz!)

xorg.cong

Section "Screen"
    Identifier "Screen0"
    Device "Videocard0"

    Monitor        "Monitor0"
    DefaultDepth    24
    Option        "CIOverlay" "On"

    Option        "CursorShadow" "Off"
    Option        "NvAgp" "3"
    Option        "TwinView" "1"
    Option        "SecondMonitorHorizSync" "21.0-140.0"
    Option        "SecondMonitorVertRefresh" "47.0-72.0"
    Option        "TwinViewOrientation" "LeftOf"
    Option        "MetaModes" "1280x1024_72,1280x1024_72; 1280x1024_60,1280x1024_60; 1024x768_72,1024x768_72"
    Option        "TwinViewXineramaInfoOrder" "DFP"
#RandR    Option        "RandRRotation" "true"   # Requires xorg 6.8.1+
#NoEDID    Option        "UseEDIDFreqs" "FALSE"
#NoEDID    Option        "UseEDIDDpi" "FALSE"
#NoEDID    Option        "ModeValidation" "NoEdidMaxPClkCheck"
#ExactMODE    Option          "ExactModeTimingsDVI" "On"
    Option        "DPI" "85x85"
    Option        "AllowGLXWithComposite" "true"
    Option        "DisableGLXRootClipping" "true"
    Option        "AddARGBGLXVisuals" "true"
    Option        "AllowSHMPixmaps" "true"
#FALSE    Option        "Dac8Bit" "true" # forced spatial dithering instead of temporal for teradici performance
#FALSE        Option        "RegistryDwords" "DitherAlgo8=3;DitherAlgo6=3"


# Other possible options. Enable at your own risk
#    Option        "RenderAccel" "On"
#    Option        "Overlay" "On"
#    Option        "SWCursor" "On"
#       Option          "TwinViewXineramaInfoOrder" "DFP-1,CRT-0"
#       Option        "ConnectedMonitor" "DFP-0,CRT-1"
# This can be used to clarify orientation
#    Option        "TwinViewOrientation" "DFP-1 LeftOf CRT-0"
#    Option        "IgnoreDisplayDevices" "CRT"

    Subsection "Display"
        Depth        24
        Modes        "1280x1024_72"
    EndSubsection
EndSection

Why IT practises are bad for broadcast installs

I'm in the middle of a big build where (in common with lots of film and TV facility builds) we're a subsidiary to the IT department and so have space in their comms room rather than have our own MCR. There are quite a few standard practices in building IT installs that don't map nicely onto the optimal configurations for TV builds;

1. Air conditioning - I go on about this endlessly but having done this many times I have a few observations about why under-floor hot-cold isle comms room cooling isn't suitable for TV equipment (and in fact it's not really suitable for IT builds!). Nobody in IT server-room construction has ever been able to answer me any of the objections below other than this is standard practice.

• Cold air is heavier than hot - why try and fight nature by pushing cold air upwards rather than dropping it down the front of the cabinets?
• Raised floors leak - cable entry holes into the room and once tiles have been lifted and dropped a lot of cold air is spilling out reducing the pressure in the cold isles.
• Lots of additional brush-covers for cable entry into the cabinets
• Dust is forced out of the floor void (and into the equipment!).

2. Patch panel layout - I shudder when I see structured cabling panels where the eight tie-lines to a room just present sequentially with no thought to how they'll be used. It's just lazy and means no attention has been paid until an engineer is patching up. It also means bays are very untidy from the start and you see super-wide bays with cable-management down each side. Things needn't be that messy from the start.  This is a real comms room;

3. "Flood wiring" of cabinets - This one relates to the previous point, but by avoiding thinking about the room and over-spending on 'flood wiring' you see 24-port panels at the top of EVERY CABINET going back to the haystack above.

4. Power specifications - Despite every bit of equipment having a switch mode supply (and hence being an inductive load) every MCB in most mains rooms are C-rated and double the required capacity (C32s for the 16A circuits etc.) - I'm sure using correctly rated D-breakers would be better from a safety and reliability point of view. Again - it's about not taking responsibility early on; keep our options open!

All of these are a function of the fact that the clever part of IT installs is in the switches and servers. The cabling is generic (one cat6 is much like any other) and so there is little compulsion to do it as nicely as it can be.  My heart sinks when I start a job and the first thing the customer's PM says is "...this is off the back of the comms room build"! 

This is the way I like to leave things;

HD/SDi over fibre and SMPTE 297M (2006)

I've recently installed an NVision 8144 router at a large facility and some of the output cards are for fibre - dual LCs on each SFP with 3G video conforming to SMPTE 297M (SDi over single mode fibre). Very nice. Over the last couple of years I've put in a load of the little Black Magic fibre transceivers and although they perform admirably (only had to replace one due to it being roughly handled by an OB rigger!) but I couldn't quite bring myself to believe that the mighty Blackmagic would conform to the same spec! They really are built to budget (and excellent for it). However, I had a situation where my choice was to buy the Miranda fibre receivers (at a grand a piece) OR use the half dozen BMs I already had. To my surprise the Blackmagics worked just fine. Maybe SMPTE compliance does mean something, in the case of fibre I assumed manufacturers would juts vary too much, but I suppose SDi over copper is universal, so why not over glass as well?