The Engineer's Bench podcast - "Beyond Colour Bars"

Phil and Hugh talk about modern picture quality analysis and why good old fashioned colour bars are of little use to the modern broadcast engineer!



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

Poor RGB separation in Plasma TVs and poor Barco broadcast monitors!

I spent a day over the weekend at a customer's facility; they are a large production house with a decent number of edit, grade and audio rooms. An old industry pal has recently become the tech manager there and he's trying to get them up to standard. So - I've been in calibrating monitors and he also asked me to give him an assessment of how easily he could LUT their plasmas to get them to Rec.709.

The first observation is how bad Barco broadcast displays have become! I was very used to them in the eighties at the BBC but the RHDM-2301 is a sorry excuse for a TV monitor.  The marketing material say; 

The RHDM-2301P is the perfect reference monitor for Directors of Photography (DoP) on set during film acquisition, as well as for dailies processing. The Grade-1 color accuracy and stability means that two RHDM-2310P monitors will show identical pictures even on two distant sets.

Which might be the case, but the problem is that they only give you access to adjust the white-point of the monitor (which on these two were both wrong AND different; one was a tad blue, the other a tad red) - the menu tells you what the CIE 1931 color space chromaticity coordinates of D65 are, namely x=0.3127, y=0.3290 but the monitor is not kicking out that colour - it was a bit blue in the white; around x=0.3045 and y=0.3315! This is why monitors tell you what RGB values they are driving and you measure and make the display correct using the x,y,Y values off you photometer or spectralradiometer. For them to tell you what the white point is in terms of x & y and them be wrong is monstrous! They do allow you to tweak the x & y but only in the whites; the monitor is also incorrect in the blacks; greyscale tracking is wrong!

It's also kinda pointless for them to tell you the values of the primaries as well! They can't be adjusted.

So - rant about Barcos over, here are some test results for the cheaper Panasonic 32" plasmas they also had;

Using LightSpace I profiled the display. You can see the gamut of the TV is bigger than Rec.709. The other worry is how bad the RGB separation is. However; after taking a 17-point profile (around 5000 colours) the software reports better than 100% compliance. Good news!

















This is the resulting LUT cube and you can see 709 is entirely contained. There are no tightly packed points anywhere indicating a LUT will make things better.

So, loading the cube into our ISmini LUT box and re-running;

Reliable Avid ethernet traffic over old fibres

The first Avid Unity fibre-channel SAN I installed was in 1999 and fibre was the standard for high-speed shared storage for editing for more than a decade. However; since the introduction of MPEG4-based editing codecs which allowed Avid to offer high quality DNxHD we've been all about ethernet-attached shared storage; in Avid's case the ISIS storage products.

We have had a lots of customers who went to the expense of running OM3 (50 micron multi-mode fibre) cable only a few years ago and are now cheesed-off that they need to flood their facility with cat6 or 7 because the rough-old cat5e they have doesn't work reliably for gigabit. So; the obvious choice is to use that fibre which had bags of bandwidth for ethernet but until very recently that was not an approved configuration by Avid. Recently they have tested Allied Telesis media converters and given a cautious thumbs-up. BUT, they are very expensive (a few hundred quid per workstation, so back to running new cable), but I had a quick chat with the guys at Comtec about the house-brand they supply which uses the same chipset.

Neal Kemsley kindly ran Avid's PathDiag tool before and after and these little cheapies seem entirely transparent. Here's what he fed back to me;

"Windows ISIS client attached directly to a Dell N3048 switch running Pathdiag in an “Unlimited” Writes then Read PathDiag test cycle targeting an ISIS Workspace (the term used by Avid for their storage volume – the same as Unity). Unlimited means that the test attempts to saturate the channel between the ISIS client and is a good indicator of the upper limits of the potential connection between the client and the storage. In this case it is a 1 Gbit copper connection to the switch, and an optical 10 Gbit connection between the switch and three ISIS 5500 storage chassis. As you can see we are getting a result north of 100 MBs per second – yes that is MegaBytes – not bad for a 1 Gbit path! (Not too shabby as they say in Boston!)"

"This one shows the same test parameters but with the client attached to the switch using the media converter pair in circuit. Note that the test results are really similar perhaps with some minor variation in the upper reaches of the test during the write cycle but nothing serious. The overall speeds achieved during the tests are essentially the same as a direct connection and there are no errors displayed.
Note that the graph pattern drawn by the test is relatively clean showing very little spiking or variation and clean transitions between the Write tests and the Read test cycle. Note also that no errors are seen in the error count on the right side."

"We would want to run the test for several hours to draw conclusions on this but these results are very promising. We would probably want to also change the Transfer Size parameter of the test up and down to emulate different editor timeline characteristics. Smaller values are used to emulate working with heavily compressed material, the current setting being used to emulate working with DNxHD material, and larger values can be selected to emulate working with uncompressed HD and UHD material."

"To emulate working with several streams of data in a timeline this shows four independent PathDiag test sessions running simultaneously with the Media Converters in circuit. In this case rather than working with unlimited tests, I set the Transfer Rate parameter to 25 MB/sec and allowed the tests to cycle for 30 minutes. Notice for results graphed in these tests the individual tests are interacting somewhat – see that the top value levels are becoming choppy and castelated somewhat as each test competes for throughput. Since the tests in aggregate are pushing the maximum limit of the channel (if all four tests happen to be writing or reading simultaneously, the overall write or read bandwidth should around 100 MB/sec) this interaction is quite normal and will get worse if similar test were being run on further clients in the ISIS environment as each client competes for access to the storage."

The Engineer's Bench podcast - "TV Colour 3 - using LUTs for calibration"

Hugh and Phil go over the practice of using a 3D LUT (look up table) to get OLEDs & LCD televisions closer to the Rec.709 gamut.



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

Using a monitor LUT to try and tame domestic TVs for grading rooms

The venerable old Rec.709 colour space was first proposed in 1990 for HD Television and we still work to it today and the assumption is that pro/broadcast monitors will faithfully translate the Y, Cr, Cb data that comes down a video cable to the R, G, B pixels on the display surface.

For a Sony BVM-series monitor merely doing the following will ensure correct 709 operation;

1. Set the overall black level using PLUGE so that dark areas of the picture are faithfully reproduced.
2. Set the peak-white of the monitor to around 80Cd/m2
3. Check the colour of the white point so that it sits as near to 6504 kelvins as possible
4. Check the 10% grey point for the same colour; track up to peak white and ensure the colour temperature remains constant
5. Check the saturation by putting the monitor into blue-check mode and match the blue coming through the luminance path to the blue coming via the Cb channel.
6. Go back and do it all again as the controls interact somewhat.

However - along with the £18k BVM monitor at the front of the grading suite you also expect a high-end domestic TV for the producer and director to look at and of course they don't want to see any differences! So; here are a couple of monitors we profiled today;

Panasonic TX-50AS500B LED-backlit LCD TV

LG 55EC930V-ZA OLED TV

I used the following to profile these two televisions;

• Klein K10A photometer - my colour probe of choice
• Fuji IS-mini patch generator / LUT
• LightSpaceCMS software to drive the Fuji and read the Klein

Looking at the results would suggest that both displays are almost bang on; in fairness I did try and get them as close as possible using their built in colour-tweaks. The other things to pay attention to is to disable all the dynamic modes; TVs increasingly try and tweak themselves based on picture content or even ambient light and although those things may be great for watching a movie it's hopeless for TV post-production usage. 

It's not just the overall gamut that affects the look of pictures, you have to pay attention to the gamma of the profiles. This is not the same as the 2.2 / 2.4 gamma used between cameras and monitors, rather the relationship between low and high levels for the RGB channels and ideally it should be linear.

LG OLED - although it seems more linear overall it has a strange separation in the blacks.











Panasonic colour gammas - not ideal!  Funny non-linearity in the blacks and poor colour tracking in the mid-tones.









So, once the displays are profiled (it takes around an hour and a half to read the 4900 points that make up a 17-point LUT) you can examine the resulting "cubes" that can be downloaded into the LUT (the Fuji in our case) to make the TV look as close to Rec.709 as possible.

The LG-OLED cube shows that the monitor is capable of displaying almost the entire colour-space but there is a bit of a lump missing from the yellow and the magenta ends. This doesn't mean that those colours aren't available, only that the LUT is having to do the work in transposing the colours in those parts of the gamut with the attendant loss of dynamic range.

Interstingly; that was the first thing the colourist noticed on real pictures "...the magenta in the blacks looks a bit off".

The Panasonic's derived monitor LUT shows a different story; clearly the dynamic range of an LCD is much more modest than the OLED.

To turn the profiles into LUTs you have to use the "convert colour space" in LightSpace. Selection of Peak Luma, or the alternative Peak Chroma, defines the parameters the LUT is generated with - Peak Luma maintains the peak Luminance of white, while Peak Chroma will drop the Luminance if required to prevent colour channel clipping, if the peak Y value of a colour channel is greater than that of whites.

Once converted you can export the LUT in a variety of formats for use in other manufacturer's converters. One nice touch is that if you "select all" LightSpace will write out a folder of LUTs in every format it supports; takes around a minute and means you can hand a USB stick to the customer without any worry of incompatability. 

So - once loaded into the Fuji both TVs were now a darn sight closer to the look of the Sony BVM monitors. The problem is that you're in a dimly lit room with the golden eyes of a highly-paid colourist and it's remarkably difficult to get them to be happy if there are ANY discernible differences. The one chap I was talking to today did finish the conversation with "...still, if you could get a £2k TV to look exactly like an £18k monitor we would never buy £18k monitors!"

Once final point - the client had bought an AJA LUT to use - loading the derived LUT into the AJA looked no different from the Fuji from a colour point of view but it did show banding in the Cr channel - like it is only an 8-bit LUT; I need to chase the further.

OLED TVs in grading rooms?

I was over at a big facility this morning in one of their grading rooms setting up a Sony BVM-E250 OLED display for grading (the usual - rec.709 80Cd/m² - BBC-style) and as even the monitor was only a bit out; If I didn't have the probe out and ready I might not have bothered!

However, they also wanted me to see if I could match an LG-55EC9300 55" OLED tele. It was one of those new jobs that has a subtly curved screen. I'm convinced that's just for strengthening as the panel is so thin there is no way it could be mechanically stable if it wasn't build on a curved sub-frame!

Anyhow - that model only has the domestic-type tweaks; you can turn ClearPixel_TM and SmoothMotion_TM (or whatever they call those horrors!) on/off but no colour-balance in the blacks and so I spent a while changing the "warm" and "dynamic" setting to get a consistent 709'ish balance between the blacks and whites and thought that on test signals and real pictures it looked pretty close; a tad magenta in the dark-areas and I couldn't quite get the saturation to match exactly on all material, but if the two monitors weren't next to each other you wouldn't be able to remember the differences.

Here are the settings (if they're useful?)

Picture Mode: Expert1
Picture Adjust
OLED Light: 60
contrast: 63
Brightness: 52
H/V Sharpness/Tint: 0
Colour: 45
Expert Control
Dynamic Contrast/Edge/Colour filter/Expert Pattern: Off
Gamma: 2.4
White Balance:
Colour Temperature: Warm2
Method: 20 points
Pattern: Outer
IRE: 100
Luminance: 100
Red: 0
Green: -16
Blue: -2
Colour Management System (Saturation, Tint, Luminance)
Red:0, 0, 3
Green: 0, 0, -5
Blue: 0, 0, 5
Cyan: 5, 9, 1
Magenta: 0, 0, 3
Yellow: 10, 1, 2
Picture Options
Noise Reduction/MPEG/Real Cinema/ Motion Eye care/TruMotion: Off
Black Level: Low

Oscilloscope Watch update

New update from Gabriel Anzziani, the developer;

Hello Backers! Sorry for the delays, the project is still moving forward. I have received 50 PCB assemblies and other parts for the "Hacker Special" and "PCB Assembly" backers. 

 Hardware 1.5 PCB Assemblies

Below is a close up of the PCB. The board has been extended sideways to be able to add two more mounting holes, and I have also added some cutouts on the PCB (between the buttons) to hold the backlight.

 Close up of the PCB assembly

 

The board works as expected:

 Board powers up

Before I send out these units to backers, I want to finish up the backlight piece, which also doubles as the holder for the LCD, so the PCB assembly can be one solid piece.

 PCB Assembly with backlight/holder

 Backlight/holder side view 

I will be working on this piece in the next few days and I will send out the design to the mold company. I expect to have sample pieces in a month or two. While I wait for the backlight, I will continue to work on the enclosure and other details of the design.

 I'm still itching to make part 2 of my review video, meantime, here is the first clip;

PSE and the DPP - a whole lotta flashing going on

 One things that seems to have to come to light since the introduction of the DPP delivery spec at the start of October is just how badly folks understand the requirement for PSE (Photo Sensitive Epilepsy) with respect to TV deliverables. A lot of this is down to the fact that since the late '90s the industry has essentially had two standards - OFCOM and Harding. 

I did a talk to NBC-Universal's TV dept in July and you can snag the notes here - pay attention to p.12 to see why the important thing now is that the metadata of your AS-11 file needs to specify what algorithm was used and pass/fail.

For a (slightly noisy!) audio recording - download here.

For all the notes and test clips - Google Drive folder

Article in Broadcast Film & Video magazine, no.2

Wow - I'm appearing in this magazine every month at the moment! This article is all about "value-added systems integration"

Article in Broadcast Film & Video magazine

This is an article in Broadcast Film & Video which was a re-write of a presentation I did over the summer. You can see it as a PDF here.

The Engineer's Bench "Video Compression 101"

Hugh and Phil go over the principles of the Discrete Cosine Transform as applied to video compression and the differences between IFrame and long-GOP codecs.
Find it on iTunes, vanilla RSS, YouTube or the show notes website.

Why do manufactuers over-specify power requirements for broadcast equipment?

It's actually a rhetorical question and I'm glad they do. Most of the time I have to tell a customers' electrician and air-con contractor how much power (and hence how much heat) the machine room will be pulling/genarating. Most customers refuse to believe that 99.9% of the electrical power entering a server room/TV MCR leaves it as heat! Just think about it; a 1v video signal leaving the room and terminating into 75 ohms represents a tiny amount of energy. Everything winds up as heat and so I've got to the point where I tell the electrician how many amps we'll need and the aircon guy how many BTUs of heat he'll have to move. By turning them into different units the customer stops complaining!

Anyway - why are the numbers always so different? I've been installing Avid shared storage chassis since 1999 when Unity v 1.2 was considered clever - 500 Gigs across three arrays and usable by around ten edit rooms. Fast forward to 2014 and the ISIS range are what you'll buy from Avid and the new ISIS 2500 near-line storage is just the thing for cheaper, non-edit storage.

This is the rear of this monster - two supplies with 20A C19 inlet connectors and you can see from the clamp-meter that the thing is pulling 1.3 - de-powering one of the supplies shows the current draw by the single supply rise to 2.6A (so they are properly balanced). Re-powering the thing shows that the total draw across both PSUs rises to 3.3A for around thirty seconds but settles to the total 2.6A once everything is up and running. 

So, P=IV and (not forgetting the inductive load which has a power-factor of 0.8) means we are seeing a bit less than a kW max. However - on the Avid website;

 

Earth Leakage - in water!

I recently bought an Agilent U1191A clamp-meter. This is a piece of test equipment that can measure current flowing in a conductor without having to break the circuit (how you would if all you had was a digital multimeter). The jaws physically couple around the conductor in question and by induction you can measure the electrical current flowing in the conductor. 

Clamp meters have moved on somewhat since I last had to buy one (a Fluke; sometime in the late nineties). This one is a pretty competent DVM as well as being able to sample and hold min, max and average values across all setting. For most days it could definitely do double duty against my Amprobe 37XR multimeter - EXCEPT the Agilent doesn't have non-contact voltage detection (the Amprobe does!). Anyhow - how do you get four and a half digits of resolution across multiple ranges on a brand-name test set for less than a hundred quid? Engineers today, don't know they're born...!

Today I was called to a customer's site where they have three canal-barges, each with two or three edit rooms on board. In the bilges of each boat there is room for little half-height equipment cabinet where they have the shared-storage chassis, network switches etc. They've been suffering an unusual number of equipment failures (motherboards dieing etc) and since they also seem to have RCDs tripping out as a regular feature my first thought was earth leakage.

Here is a picture of the electrical termination point for each boat - two 32A feeders go into the hull, one for the pumps and one for the mains distribution board. The cables are permanently suspended in the water (and have been for many years!) and the ones I inspected had clearly been submerged for so long there has been lots of water ingress into the rubber jacket of the cables. One felt almost ready to crumble in my hands.

Insulation has both electrical resistance and capacitance – and it conducts current through both paths. Given the high resistance of insulation, very little current should actually leak. But -- if the insulation is old or damaged, the resistance is lower and substantial current may flow. Additionally, longer conductors have a higher capacitance, causing more leakage current. Attaching the clamp meter to the incoming earth bond (pre-the consumer unit) measured a massive 100mA of leakage current. This not only risks the equipment being fed off this supply - there is an imbalance between the live and neutral cores and Class-1 equipment is often upset by this, and power supplies can pass this residual current to the earth-plane on PCBs.

More worryingly you've also compromised the safety action of any RCD (Residual Current Devices) in the feed. 

So - my advice was; replace those 32A feeders with marine-grade power cable as soon as possible.

Perceptual video quality & compression - PSNR measurements

Compression is a fact of life, there have only been two production VTRs that stored uncompressed video - D1 and D5; they are no longer used because they were both SD (and D1 was only eight-bit video). So, the vast majority of the material we handle is compressed and so there should be a way of quantitatively judging it. There three methods of numerically analysing how good pictures are, but for the most part and engineer or editor proclaiming "...those pictures look a bit soft" is what still passes for picture quality analysis! 

Don't regard this blog-post as definitive (which of my rambling are?!), but this comes from a discussion with a couple of industry colleagues earlier in the week about the quality of satellite contribution circuits. They'd got into a bit of a to-and-fro with the carrier over bit-rates and chroma-sampling structures ("but 4:1:1 isn't as good as 4:2:0 for the same data rate" etc.) which for my money entirely misses the point. You have to assess the picture quality of a compressed link (satellite, IP, etc.) not on encoder settings but on perceived picture quality. A few thoughts;

1. Modern codecs perform better than older codecs when considering data rate vs quality
2. Progressive pictures compress nicer than interlaced pictures
3. Statistical multiplexing always produces better results over multiplexed connections
4. Long GOP codecs outperform iFrame codecs by a factor of 5:1 typically.

The three methods used for determining video quality are;

• Peak signal-to-noise ratio - PSNR
• The "Just Noticeable Difference" or JND; a very BBC-type measurement and commonly derived by asking a crowd of observers to assess picture quality.  I like the idea of this and when I was at the BBC you'd often hear people specifying "...half a JND" as being a required spec; that was also know as a "gnats" as in "gnat's whisker"! It's problematic because it describes perception rather than the effect of exposure - an editor friend told me that he preferred to work on DigiBeta pictures over DVCam footage not because he could spot the difference between shots from the more expensive format over the cheaper format (all other things - camera, lens, lighting etc being equal), but the more compressed pictures just made him feel more tired by the end of the day. The JND takes no account of the cumulative effect of looking at compressed footage that may at that moment look just as good but more subtly takes it toll on the viewer.
• Mean Opinion Score - MOS; very similar to the JND but with a numeric score. I won't talk about this.

So, PSNR - to steal from Wikipedia;

...the ratio between the maximum possible power of a signal and the power of corrupting noise that affects the fidelity of its representation. Because many signals have a very wide dynamic range, PSNR is usually expressed in terms of the logarithmic decibel scale.

PSNR is calculated as a rolling set of differences between source material and the compressed version and is most easily defined via the mean squared error (MSE). Given a noise-free m×n monochrome image I and its noisy approximation K, MSE is defined as:

The point is that it can be calculated from the pixels. No observer bias is involved.
Engineers love quick rules of thumb, and PSNR for video images are no different;

• For idential images the MSE is zero and hence the PSNR is infinite (more dBs = better pictures!)
• 40dBs is considered to be indistinguishable from uncompressed production quality (that's where the BBC JND lives!)
• 32dBs is considered desirable for quality broadcast link circuits
• High twenties is what you can expect for over-the-air transmission - the 10Mbit DVB-T2 pictures you watch on Freeview or Sky.

 

So, to return to my point 1 (above) - here is a graph showing data rates against codec types for the same SD pictures. Venerable old MPEG2 (from the mid-90s!) up against vanilla MPEG4 (late nineties) and AVC (AKA H.264 / MPEG4.pt10 - early noughties). A full 6dBs of quality (twice as good in layman's terms?) lie between those two codecs at 2.2Mbit/sec (all other things being equal - use of a Stat Mux etc). You could even dive in further to MPEG2 and see the difference between the implementations from twenty years ago and what folks like Main Concepts are doing in 2014). The decoders particularly are now much better at hiding macro-block edges and recovering from corrupt frames.

Point 2 (above) seems obvious, but only when comparing 1080i with 1080p pictures AT THE SAME FRAMERATE; so perhaps best to say 1080i vs 1080PsF; Interlaced pictures will always be a challenge as pixels (and hence macro-blocks) move within a frame, unlike progressive pictures. BUT, you still get better motion rendition withing interlaced frames for the same framerate. Eventually we'll have moved to 1080 50/60P and so it'll be a moot point.

This graph shows data rate for HD pictures, we expect over-the-air HD to be at ten megabits in the UK.

So, how to make these assessments if you're worried about a contribution circuit or transmission path that you're responsible for? If you work in coding and mux then you probably already have tools to assess. PSNR is such an important part of delivery specs/SLAs in broadcast (you need to keep the accountants at bay after all!) that you'll have a Tektronix PQA600 or a Rohde & Schwarz DVMS-series test set. 

However, "traditional" video quality measurement needs access to the compressed signal and the original which may not be possible; particularly in the case of my pals who are at loggerheads with their satellite provider. What you need is a test signal that you can feed over the connection and then make an assessment from the picture content as to how badly the pictures are being degraded. I've banged on about the SRI Visualiser before but it has a compression multiburst that shows you lines-of-TV-resolution against perceived bit-depth. You can then relate the two worst-case lines/bit-depth figures to the table of PSNR values.

 

Forgive the voice-over!

The death of videotape; long time coming.

Say it ain't so! I read the news today, oh boy.....

Sony is to stop selling its range of ½-inch tape machines and camcorders in just over a year’s time. The manufacturer has targeted March 2016 as the date by which it will cease sales and distribution of its professional VTRs and camcorders, owing to what it described as “the global trend of migration towards file-based operation”.

VTs have been a constant feature of my 26 years in broadcast engineering - I spent three years in VT maintenance when I was in BBC TV News and all through my time in facilities in the nineties/early noughties and my last dozen years working for a reseller the most dense way of storing data (which is what video has been for twenty years) is on magnetic tape using a rotating head-drum. 

VTRs are mechanical and hence unreliable; you can't pull rust-on-sellotape (a crude description of videotape) over a rotating metal drum without things wearing out and when I started I estimate that at least a half of all broadcast engineering hours were spent fixing decks. I certainly enjoyed that mix of electronics and mechanics and when I left BBC TV news my supervisor in VT maintenance had this made for me - at the time he reckoned I had done more than a hundred head-drums.

So, here are a few memories about VT formats I have had to deal with. It was all analogue when I started with the D1 format just starting to make inroads. By the mid-90s DigitalBetacam had become the predominant format for most production and post-production and Sony continued their domination of tape formats with HDCam and HDCamSR in the late nineties/early noughties. Since then it's been disk-based (XDCam) and flash-based (SxS, P2 etc etc.) - I haven't done anything more than cleaning a tape path or head-drum in the last decade but I used to be a pretty good VT-fixer!

• 2" Quad; The original broadcast tape format which was on the wein when I joined the Beeb. At Lime Grove studios we did have a couple of Ampex VR 2000 machines. These beasts needed a compressed air feed to hold the tape on the transversely rotating drum. They weren't used for editing, just for archiving P as B recordings. I remember watching an episode of "Star Trek" (original!) being transmitted and marveling at home good composite pictures could look.
• 1" C-format; specifically the Ampex VPR-2B (which was the BBC's 1" of choice) was a bit more of a workhorse machine. Again, BetaSP and Umatic HiBand where more prevalent at BBC News when I was there but when I went out into the independent industry in 1993 1" was a lot more widely used, particularly the Sony BVH-series machines (the choice when I was at CTV in St John's Wood) and then the Ampex VPR3 when I got to Soho in 1994 mastering to an analogue format was already diminishing.
• BetacamSP; The BVW75P was the first piece of broadcast equipment I got to know to the component level. The summer after I joined the BBC they bought three hundred of them and I jumped on the overtime to do acceptance testing. Consequently I got to know the signal path and then in 1990 I got transferred to VTR maintenance and pretty much serviced the same machines I'd been taking delivery of two years before. They were the broadcast workhorse until the late nineties and I still see them. When I went to Nigeria the whole place was still running on them. Here are some photos of the insides.
• D1; I didn't get into Soho until the second generation of D1s had arrived - the DVR2000 series (the 1000 series had half a rack of processing for trick-speed playback). D1 was the first 8-bit uncompressed SD VTR format. All the high-end facilities in Soho made good money out of them - when you could hire a 3 machine D1 room for £650 an hour! Many a time I heard engineers dismiss DigiBeta for it being compressed but I've NEVER seen Digi compression artifacts but I have seen shallow ramp banding on D1 (8-bit vs 10-bit). D1 decks were very expensive (£100k) and cost an arm and a leg to maintain. However - being able to do more than half a dozen generations on and off tape gave rise to all those effects heavy pop videos in the early nineties.
• D2; Sony quickly realized that they'd need a composite digital machine for run of the mill TV production work (i.e. people who needed a drop-in replacement for 1") and so they bought the format off Ampex in some complex licensing deal that allowed Ampex to sell badged BVW75s. Ampex's VPR300 was a terrible machine; we had them at Oasis TV and you could often not get recordings made in the morning to playback on the same machine in the afternoon. After that the Sony DVR28 was an eye-opener. It could stripe tapes at high speed as well!
• D3; Like D2 a digital composite machine but like D5 a 1/2" tape path which meant a practical all-in-one camcorder was possible. The BBC embraced the AJD350 the year I left and according to a pal at Panasonic of the first 98 machines they never got more than sixty working simultaneously. They format got really good after v.2 software when stability, RF performance etc improved. The operational side of the machine was entirely unlike Sony with a very complicated screen surrounded by buttons. Panasonic had to replace heads - almost no usable serviceable parts inside...!
• D5; Channel Four were the only UK broadcaster to commit to D5 which was Panasonic's answer to D1 (but, a 1/2" format with 10-bit video, uncompressed - eventually there was an HD variant as well). You could tell the machine ran so close to the edge in terms of heat performance. We had two of them at Oasis and every morning I would pull out the long boards (below the tape transport) and re-seat all the chips - a day's worth of heat made all the socketed devices rise up. The machine shared mechanics with the AJD-350 D3 machine and with an option decoder board would replay D3 tapes. The tape-stock was the same in both cases and when I was at CTV we would send "D5" masters to Channel Four which were really D3 recordings with a D5 card in the tape sleeve! They never spotted it and it saved us hiring D5 machines (we owned D3). The rumor at the time was that C4 had been given the initial set of machines free to establish the format which was (even then) viewed as entirely unsuitable for a broadcaster. I never id much maintenance on them save cleaning etc. You had to send them back to Panasonic for heads etc.
• DigiBeta; Whereas the first gen digital VTs (uncompressed, either 230mBits/sec for D1 & D5, 155mBits/sec for D2 & D3) required manual tracking for record like 1" the DVW-series 1/2" Digi had a pilot tracking tone system that allowed the machine to track itself for record. It could even do an insert edit if the control track was damaged by driving the phase of the scanner-lock based on the difference in signal strength between the pilot tones and the head and tail of each video track. Consequently I rarely saw machines that made incompatible recordings (that was a constant feature of all the earlier digital VTR formats).  The DVW was also the first machine to feature a Viterbi decoder in the bitstream path off tape and so you tended to get a green channel light (no error correction or concealment) until 1800hours of tape wear and then over a couple of days it would go to orange (error correction) to red channel condition (error concealment). Compared to all those earlier formats (I used to clean the heads on D1 & D2s every day of use!) they had a very low TCO.
• BetacamSX;
• DVCPro / DVCam / miniDV;
• IMX;
• HDCam;
• HDCamSR;
• Umatic;
• VHS;

Fibre 102; CWDM & encircled flux - The Engineer's Bench Podcast

Hugh and Phil talk about optical multiplexing as well as new methods for accurately testing fibre cables. A few tips on basic fibre cleaning as well.


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

Digital path & SDi does not colour-accurate pictures make...

Recent years have seen many prosumer camcorders with HDMI outputs so that you can get access to the uncompressed RGB sensor output rather than having to make do with the H.264 (typically) encoded Y, Cb, Cr data (from the flash or disk-based recorder). This makes lots of sense and has given rise to HDMI -> SDi converters like the ones Mr. Blackmagic sells;

These take any HDMI 1.4 resolution (all the way to 4k UHD - 3840 x 2160 at a maximum of 30P in 4:2:2 colour space) and convert to single-link (1.5G, 3G or BM's home-brewed 6Gbit/sec) SDi. Excellent, you'd think; and they are so long as you only use them for video-type sources - camcorders etc. Don't assume they are of any use in turning the output of your computer into SDi!

So, here's the test rig; my Macbook Pro 15" running Mavericks with a Thunderbolt -> DVI breakout connecting to the HDMI input of the BM converter.

 

The SDi output is fed to my trusty Tektronix WFM7100-series and I'm running a known-good recording of 10-bit, 1080 50i 100% EBU colour bars on the 2nd display.

Now let's take a look at the state of the bars; not pretty - the luminance response is all over the place with a very funky gamma that has really gone awry in the bright parts of the picture. The blue colour-difference channel is not so bad, but the Cr (red colour difference) is really crushed in the cyan end of it's response; look at the vector display (top-left).

That's not to say that the pictures don't look good on the monitor; but they aren't colour accurate in the way they need to be if you're using this as a method of profiling an SDi display - and I have seen people use this method with Light Illusion to derive the colour space of a display and then generate a LUT to make the display look how they want.

So, my first thought was, head over to the display profile and see if it's just using the wrong RGB numbers; OS-X and Windows both support standard profiles like Adobe RGB or sRGB which are more suited to print and web graphics prep but not necessarily our beloved broadcast Rec.709 colour space. Imagine my horror when I realised that the colour display profile that OS-X had used was the one that shipped with the Blackmagic! How did they not even get that right?!

To be fair even the 709 profile that comes with the OS is wrong; the take-away is don't use these kinds of gadgets if you need accurate colourimentry. For XBoxes or just getting a high-quality desktop feed as SDi they are fine, but not if accurate broadcast pictures are needed.

Ongoing Barnfind notes

As I get more familiar with Barnfind's products I need to make a note of some of their gotchas!

1. The Tx and Rx lights on all SFP ports are not data lights, rather they are clock lights and as such only light when you're dealing with synchronous broadcast signals - HD/SDi, MADI, AES etc.
2. The CWDM multiplexer/de-multiplexer (they are exactly the same unit!) works both ways and if you have signals going bi-directionally on a fibre each port is an input or an output; that takes a bit of getting your head around!
3. In a similar vein the wavelength quoted on SFPs (1350nM in this image) only really applies to the transmitted signal; SFPs are "colourblind" - they don't mind what wavelength they receive. So, once a signal leaves the CDWM de/multiplexer you can take it into any of your SFPs for input to the crosspoint router - again, it's not particularly intuitive as we're used to "tuning" or "demultiplexing" other signals to the frequency they'll be used at.
4. The BarnStudio software; the manual says that it comes set up hard-set to a 192.168.0.1 address; our didn't, it was setup for DHCP and since it doesn't respond to multicast PINGs it took me a while to figure this out.
5. If you are routing ethernet out to the multiplexer it is always directional (i.e. it takes up the in and out of an SFP and needs two ports on the multiplexer). 
6. See note 1 above (no activity lights) for ethernet.
7. If you're using the same machine to drive BarnStudio and test an ethernet connection (by sending it via an ethernet SFP -> fibre -> multiplexer -> BarnMini -> SFP -> ethernet) you run the risk of an ethernet loop and subsequent broadcast-storm! Wesley & I suffered this and couldn't figure out why the entire workshop network was down. Much better to use your rucksack router & a RaspberryPi as a separate test network.
8. The BarnStudio software - although good, is a tad hard to read initially as if you give the ins and outs proper names they re-order alphabetically rather than in order of the SFPs and BNCs. Just remember - inputs are down the left axis and outputs are along the top (most things are present in both).

HD playback - how we did it a quarter of a century ago

In 1988 I went to a demo of HDVS in Studio 2 at Television Centre; the left-hand image shows the 1" uncompressed RGB recorders that ran around eight times the speed of regular C-Format videotape. On the right is current-model Blackmagic Hyperdeck Shuttle - a small HD/SD record/playback box that uses SSDs and can handle uncompressed, ProRes and Avid DNxHD. It's in pieces 'cause I'd just finished fixing it and was testing it. BUT, given that they are two-hundred quid you might wonder if they're worth fixing?! The Sony was definitely worth fixing as each machine came in at >£100K.

Makes me wonder what I'll be doing by the end of my career?!