Communication protocols for TV processing

It is "absolutely impossible" for HIM to process, because he doesn't have the expertise. A talented programmer will have no problem processing almost anything you send him. However, it is rare for a TV company to have such a person sitting around in their truck.

Certainly, to the full-time pros out there who do precisely this type of thing for a living (myself, Peter Gridling, Frank Mitchell, Christian Winkler, to name a few) it's something we can whip up in a few hours or a few days, depending on how nuts you want to go with bells & whistles. But guys like us, who understand all the pieces (serial comms, timing systems, XML, framebuffers, TCP/IP, UDP), are a fairly rare breed.

There is no such thing as a universal protocol that any CG will understand. Chyron Intelligent Interface (IIS), for example, is a robust and fairly common protocol. The entire Chyron and Pinnacle families of CGs understand it. IIS has some weaknesses, particularly for rendering clocks. Another potential problem is that the host broadcaster may be using Aston or Dubner or nVidea or something that doesn't speak IIS.

My suggestion to you is either to hire a pro to put together a solution for you tailored to a specific broadcast host and the CG hardware that particular host uses, or else buy yourself a CG, create your own graphics and protocol, and plug your CG into the host's switcher at the event. But CGs aren't cheap. Plan on spending a minimum of about $15,000 (US) for a bargain-basement piece of framebuffer hardware, and for that money you can't touch anything that does HD. It'll be SD-only.

The technology is actually the easy part. The REAL trick is getting either the host broadcaster or a sponsor to PAY for your solution, as you'll have to invest some bucks, and you need to earn that back. In most sports, there is broadcast money at the World Cup level, but lesser events usually have no money.

At the regional level, you can also try using a VGA->PAL genlocking scan converter to overlay a VGA signal onto the host's broadcast signal. Something like a "Scan-Do" costs $1500 (US) and can do this. The signal quality is atrocious, so no real network will accept it, but if it's a regional event on a small regional network, they may allow it on the air. Certainly BBC, Eurosport, Sat 1, or ESPN would laugh at a scan converter.

So your pro graphics guys... would they be happy with me providing a file that is updated on every change of information (thus at least every second, when the running clock changes)? I would imagine them parsing it and formatting it any way they like. I would think of plain text or XML or something like that.
I could provide the file through a file share or a http connection?

If I were the guy writing the interface, I would advise you thusly:

File share - bad. Very unstable under Windows, difficult to implement across platforms (requires a rosetta stone like SAMBA to make a Windows box talk to a LINUX box or a Chyron box) and hindered by the 300-foot limit on an ethernet connection (unless you've got specialized networking equipment, or glass fiber, and a bit of networking expertise).

XML - Not my first choice. Too verbose. The problem with XML is that it frequently makes your packets too long to send via UDP, which has a practical packet size limit of about 1K.

ASCII data stream - good. Comma-delimited, fixed-length, or using tags/tokens. Take your pick. Even better if the data stream can be sent multiple transport modes, i.e via UDP if the connection is in the same compound, via serial if it has to be sent via dry pair (using long-haul modems), or via TCP/IP socket connection if it has to be sent across the internet.

Another thing you've got to be concerned about is latency and the rendering time of the CG. If your time base (TDC8001, for example) is kicking out running tenths, and your processing is taking a half-second, and the CG takes 3/10ths to render, then the graphics are going to freeze well after the rider crosses the line, which is a no-no. You've got to write code tight enough to where it squeaks. Processing time must be well < 1/10th second. If you're reading a bunch of data from DB tables and then composing & saving XML before you squirt your data, the graphics will look ridiculous - especially, for example, in track cycling, where some riders are traveling 70 km/h. If your finish clock freezes when the rider is halfway through Turn 1, then you do not have a viable solution.

By the way, I made an error in my previous post concerning Vizrt. The Vizrt VIZ | TRIO line of CGs do, in fact, support Chyron IIS. I just started a project this week on the VIZ platform, and I discovered limited IIS support in their docs.

If you REALLY want to do this "for real", at a professional level, then I would advise you to have both available - ASCII data stream (very thoroughly documented) and Chyron IIS. If you offer both data streams, in multiple transport modes, and the truck still claims they can't use your data, then THEY are the inexperienced weekend warriors, not you, and shame on them.

Hi James, thanks for your thorough responses. The graphics guy which is hired by the (national, in this case) TV station is not a weekend warrior, he just is more happy with the hiring of their familiar timing guys to do the time trials, rather than helping another timing company get their things on the road. The event, though, will be left unhappy, because this one stage solution don't fit into what they've come up with to do the overall classifications (namely, the other timing company, that's just not ready for the life feed).
So at current this is more a matter of me whipping something up to make everybody happy at a reasonable cost, so I'll end up spitting out stuff on a serial line, and as long as I properly document what I'm spitting out, you have me convinced that the graphics guy should not complain too much anymore. Thanks.

For rankings and captions there's no need to resort to low-level protocols. I think you only need to get down to bit-level programming for on-screen real-time clocks. I greatly respect anyone who's cracked that problem.

For Tour de Langkawi years 2003-5 I devised an XML format and made it available to TV over HTTP on a LAN. The TV chargen contractors wrote code on their side to interpret my XML onto a RTX/Inscriber system.

The advantage of XML is that the output is useful for other purposes too & in the event of LAN failure, I could just send over the files on a memory key. It also meant that once they'd saved the files over on their side, I was free to leave the site & get in some quality time by the nearest tropical beach.

We are discussing real-time data, not results.

The shortcomings of XML and of drive sharing for feeding CGs with real-time data on live TV are addressed above. Unless, of course, you've got a technique for swapping memory keys "every few hundred milliseconds".

James,

I agree that displaying a real-time running clock and constant updating time to beat is the perfect solution. I admired this work greatly on the TDF. It takes rare talent and skill to do this.

Revised rankings can be rendered in less than a second. In my experience, this is acceptable. At least, in the lower budget events.

At events I service we cannot afford to put up a real-time clock on TV, so I concentrate on displaying the rider's time and the revised rankings as soon as he's crossed the line. The update is virtually instantaneous as I'm getting the times directly from the TDC8000. It's on TV as quick as it's on the Alge displays.

While displaying the finished time and rankings/scoreboard only is certainly not as good as the amazing service done on TDF, it's still useful. It's an option for low-budget events.

My point is to suggest that there are two parts to the TT solution: 1: Real-time running clocks. 2: Revised rankings and static captions.

Sorry, if this analyis was a little off-topic.

I don't use drive sharing, the XML can be accessed via HTTP served by Apache over ethernet. It's very robust. Modern PCs are very quick at parsing and rendering XML.

As to your memory key remark, I take it that this was intended to be sarcastic.