Hi AC.... author here... and ouch! :)

My main motivation for writing this paper (or article or whatever it is) is that I was fully aware that most people were thinking along the lines of circuit-switched TV production moving in a packet (and frame)-switched direction - the problem was that there was very little written about it, and what it would mean for the industry. Perhaps this sort of commentary isn't appropriate for SMPTE - it's certainly up for debate. But I wanted to write about it, and having written it, I submitted it to SMPTE on the off-chance they'd be interested. I felt that they wouldn't be interested for exactly the reasons you mention. Turns out, they were.

Yes, there's no new scientific or engineering knowledge in the paper. But I wanted to start the conversation. Multicamera production is a specific niche of the broadcast industry that packet-switiching technology hasn't yet penetrated. I did a lot of searching of trade publications and saw very little discussion of what this transition would mean and challenges it would pose. I don't personally have a lot of research resources at my disposal other than Google - and that was good enough to obtain the back-of-the-envelope figures you see in the paper. At least I cited my sources to allow them to be criticised. And I want criticisim such as yours. In an absence of publicly-available of information about the future of where the industry is going, I felt my paper would fill a gap. Judging by many of the comments here on Slashdot, despite it's failings it has succeeded in informing a wider audience about the issues that this transition will face.

I do take issue with your argument that laser transceivers are not interchangable with video routers. The entire point of the paper is that Ethernet switches will replace video routers (and other anciallary TV equipment such as CCUs). We will plug our cameras and vision mixers into Ethernet switches and will not need video routers. So a comparison of their relative costs is entirely appropriate - it's a direct replacement of one technology with another. Ethernet equipment follows a steep price curve because it is a commodity product. Broadcast TV equipment is not a commodity product and is not subject to nearly as steep a price curve - meaning that in 2015 Ethernet equipment will be much cheaper than today but TV equipment will not be. Yes the predicted figures are rubbery - I don't have access to proper price modelling and market research - that stuff isn't available for free. But I wanted to crunch the numbers in a way that would more show the relative orders of magnitude in play and general trends. I think the comparisons are good enough to get people thinking serously now about developing live-production systems that connect directly to Ethernet, eliminating baseband transmission entirely. Can you go out and buy such a system today? No. So it's not a solved problem.

I would be absolutely delighted if someone read my paper, recognised it's failings and decided they could do much better. I'd like the quality of discussion to be much higher. I want to see more written about this and there to be fierce debate. Debate is already beginning about acceptable levels of latency in a live-switched production facility. Despite your assertion that these discussions are a waste of time, I assure you there are those in the industry with differing opinions as to what constitutes an acceptable level of latency. Perhaps this is where more scientific research is needed - and I would like to do some trials on this at my workplace. Also - is resource reservation really going to work? Elsewhere in the comments on this page there are those with doubts about this. Is Audio Video Bridging the right technology, is it really needed, or are more standard QoS measures sufficient? Cisco and Xilinx are addressing these issues but they are being trialled in distribution and contribution environments - point-to-multipoint or point-to-point situations. What about the massively-multipoint-to-multipoint environment that is a live TV production facility (where latency and synchronisation are extremely important)? What are the engineering challenges in building an entirely Ethernet-based Vision Mixer? I covered a lot of ground in the paper but didn't delve into a lot of detail - I more wanted to get people thinking. These things may be obvious to some segments of the industry but there's precious little discussion in the live-production area - we're a very circuit-centric bunch so the packet-switched message needs to be delivered with a simple blunt instrument sometimes.

Most of the papers presented at SMPTE and other conferences (and articles in trade publications) are product-focussed. They aren't open sales pitches but they almost always are mentioning products or services that are or soon will be on sale. This is quite OK, but I still would like to see more papers that are more general in nature, that discuss standards and technology in a more general way. Writing papers is not my day job (obviously) but I do feel I have something to contribute occasionally.

Yes, Ethernet switches frames. Conflating Ethernet and IP and TCP does makes me look a bit stupid in front of an IT engineering audience. Yes, "packet-switching" should really only be used to refer to what's going on at Layer 3. I absolutely do not pretend to be an IT engineer - my background is circuit-switched TV, which doesn't have the tradition of deep abstraction the way Computer Science has. My networking knowledge is self-taught and I know more about it than most of my peers - which is more than enough to do my job. But I appreciate being called out on my terminology flubs and resolve to do better next time. :)

Oh that's nitpicking. :) 1080i is interlaced so it has 60 fields. Typo, if you like.

100Gbit Ethernet would be very handy in plugging 30 cameras into a vision mixer. Or into a multiviewer. Or into a processing box (aspect ratio conversion, standards conversion, color correction, etc), or for recording into a video server. Inside a production facility there are 100's of uncompressed video signals flying about. Building these facilites where every signal needs it's own cable is expensive and time-consuming. It'd be much nicer to have 2 connectors instead of, like, 80 to plug into a device.

By CS I mean I'm trying to get TV-industry people to think more abstractly about CS-like concepts... like abstraction. :)

My bad, that one slipped through. I thought I had corrected it in a later draft - but I was basically conflating Ethernet and TCP for an IT-knowledge-challenged audience and I had a word limitiation. Oops.

We do too - lots of signal converters all over the place. But I wouldn't use a Blackmagic as the facilitiy's main router.

Hi Above, article author here.

I thank you for your criticism. I had hoped I'd get more comments like yours - so far yours is the only one, but that in no way diminishes it's relevance. Yes, the jury is out on the resource reservation issue - that's the most concerning part to me. I don't think in any way we should jump into packet-switched live production without doing extensive trials and tests. The reliability afforded by circuit-switching should not be given up unless the successor technology can give the same reliability (or 99.9% of the same reliabilty or whatever the market dictates).

However, I do think that Audio Video Bridging looks promising - standardised QoS management at layer 2 gives the concept the best possible chance of working. AVB's first application is for automotive and public-address sound systems. The audio production industry has been using proprietary Ethernet-based audio transport systems for years. AVB is an effort to replace these proprietary systems with open standards. But the point is, they obviously do work - I haven't read any accounts of how packet-switching is generally failing as an audio distribution medium.

That said, AVB is nowhere near ready for broadcast television - current AVB switches are only 1GB-per-port. My article was written in part to point out the economics of using Ethernet-based systems vs. Circuit-switched systems. The economics of packet-switched facilities will push development of more reliable systems. TV broadcasters face tightening budgets, so there is a big impetus to make this work. There was similar criticism of station automation. Fully-manned control rooms are always going to be more reliable than a mostly-automated station. Still, TV stations perservered with the teething problems (and there were many), and now most playout control rooms in most TV stations are run by one person (or none).

Author here. The numbers of CFP modules accounts in the article accounts for both ends of the links required. :) In my first draft I forgot that, but added corrected it in the version online. The numbers still favour Ethernet as being cheaper by 2015. I did point out that to account for bias I over-estimated the Ethernet costs and under-estimated the tradtional TV equipments costs. Even with these biases in place, Ethernet still works out cheaper by 2015.

By the time we see 4k in outside broadcasting, we will have Terabit or even 10 Terabit Ethernet.

I'll keep that in mind when submitting my next paper to Slashdot. :)

Coordinating signals implies delaying them, inside the facility where the show is being produced. You're right - latency doesn't matter for the audience as they only see one point of view and are largely passive in their consumption. At the place where the show is produced, the director is interacting with the event in real-time. Gamers hate lag, and so do TV directors. In a TV control room, directors get very pissed off when the video doesn't cut at the *very instant* they press the button.

Blackmagic stuff is nice and cheap, but you wouldn't use it in a proper studio. :) So go up an order of magnitude in cost when dealing with reliable equipment.

Hi, Author here, I'll answer the question. :) Yes, you are technically correct that buffering all the incoming signals with produce an output where all the sources are in sync. A couple of problems with this: As you're probably aware, codecs used in the broadcast industry are patent-encumbered. And has been mentioned, in a typical TV studio there are 100's of video sources and 100's of video destinations. A codec on each and every one of these would be expensive, to say the least, and a nightmare in trying to ensure full compatibility and consistency (not all implementations of codecs are equal). With uncompressed this is not an issue at all. The other issue is that adding latency to each and every signal every time it enters and leaves a piece of equipment creates a plethora of timing planes within the one facility. Another headache I don't want, which we don't have with uncompressed. Also, live-produced television is produced in real-time (believe it or not). So the director is interacting live with the content he/she is switching - talking to commentators, reacting to events as they happen, etc. You're aware that gamers hate lag? It's exactly the same with directing live television - it's interactive, and lag/latency is the antithesis of interactivity. Lag is not a problem with the present, circuit-switched, uncompressed methods.

Yes. My article is talking about live-produced content. And as Ethernet bandwidth is increasing faster than video links (in the broadcast industry), I think Ethernet will easily have enough capacity if and when we start doing outside broadcasts in 4K.

A typical vision mixer unit (VMU) seen in a studio or outside broadcast truck can have up to 80 x 1080i inputs, and at least 40 outputs. Newer VMUs have more than this.