100GbE To Slash the Cost of Producing Live Television

New submitter danversj writes "I'm a Television Outside Broadcast Engineer who wants to use more IT and Computer Science-based approaches to make my job easier. Today, live-produced TV is still largely a circuit-switched system. But technologies such as 100 Gigabit Ethernet and Audio Video Bridging hold the promise of removing kilometres of cable and thousands of connectors from a typical broadcast TV installation. 100GbE is still horrendously expensive today — but broadcast TV gear has always been horrendously expensive. 100GbE only needs to come down in price just a bit — i.e. by following the same price curve as for 10GbE or 1GbE — before it becomes the cheaper way to distribute multiple uncompressed 1080p signals around a television facility. This paper was written for and presented at the SMPTE Australia conference in 2011. It was subsequently published in Content and Technology magazine in February 2012. C&T uses issuu.com to publish online so the paper has been re-published on my company's website to make it more technically accessible (not Flash-based)."

Comments

It is going to be awhile

[zbobet2012]

100GbE is huge demand for core infrastructure people due to backbones being strained everywhere by the explosion of online video usage. Tier 1 providers are simply at a demand level that current foundries can't even come close to providing. Thus no one has an incentive to slash prices.

Re:It is going to be awhile

[Meshach]

100GbE is huge demand for core infrastructure people due to backbones being strained everywhere by the explosion of online video usage. Tier 1 providers are simply at a demand level that current foundries can't even come close to providing. Thus no one has an incentive to slash prices.

That is the main notion I got from the summary: I have an idea for a cool technology but it is a long way from becoming reality. Same fate as interplanetary travel and zero-calorie beer.

Re:It is going to be awhile

[kasperd]

Thus no one has an incentive to slash prices.

But then they have incentives to ramp up production.

Re:It is going to be awhile

[Anonymous Coward]

That is the main notion I got from the summary: I have an idea for a cool technology but it is a long way from becoming reality. Same fate as interplanetary travel and zero-calorie beer.

Not only that, but it's assuming 1080p as a standard for hi-def broadcast.

By the time this tech becomes a reality, they'll need to start worrying about 4k HD (or even 8k), and they'll need another jump in bandwidth to keep up.

Re:post you own paper day on /.

[Anonymous Coward]

And not to mention that, in the last year or two, it's become 'Any Crappy So-Called Story From-Or-About Australia Will Do day' on Slashdot.

Why?

[miffo.swe]

Im sorry but i fail to see any reason to throw around uncompressed footage. Considering the abysmal quality of HD content once it reaches the viewer it seems overkill. Until we get a lot better signals out to the homes its just wanking because a normal HD picture is compressed around 96 times. That the footage at the broadcast is uncompressed does not help one tiny bit.

Re:Why?

[Z34107]

I don't think this is for broadcasting to home users. This newfangled 802.1Qav protocol requires compatible hardware at every hop, and for the broadcaster to know the MAC addresses of the recipients ahead of time.

Re:Why?

[ustolemyname]

A summary of reasons (From the fine article):

• Dominant reason is latency. Throwing around compressed video forces latency of at least 1 frame, in an industry where latency is measured in fractions of a scan line (single horizontal line in a frame)
• Would need encode/decode hardware at every endpoint, this would add a lot of cost.
• Compressing, uncompressing, recompressing video increases artifacts, can smooth/blur out the footage.

As well, not everybody viewing HD footage has a shitty provider, and giving providers the excuse "it comes that way" won't help anybody.

Re:Why?

[tysonedwards]

The intent here is to replace so much of the specialized cabling for lighting controls, audio, video, camera control systems, etc. with a single, multi-purpose system that can handle uncompressed data, thereby supporting existing models of data acquisition. Each level of re-compression and transcoding results in a loss of quality.

Re:Why?

[realkiwi]

Because before compressing the video you have to move it from the camera to the editing system. The less often you compress the better the quality of the final compressed product. Once the live broadcast has been edited it will be compressed just once before delivery to the end viewer.

Re:Why?

[snicho99]

Well that's a failure of imagination. I'll admit technically speaking it often is *somewhat* compressed, - eg. 422 Subsampled chroma at least. But there is a massive difference between a delivery codec and a signal you're still working with. To start with H264 and their ilk are computationally expensive to do anything with. A single frame of 1080p is a pretty big dataset, and it's painful enough doing basic matrix transforms, but adding a bunch of higher level computations on top of that?... For example just cutting between two feeds of an inter frame compressed codec requires that the processor decompress the GOP and recreate the missing frames. Several of orders of magnitude more complicated than stopping one feed and starting another. And generally speaking the uncompressed feed you have in broadcast situation you're doing *something* oo. Switching, mixing, adding graphics, etc. But the biggest question is one of generation loss. Even one round trip through one of those codecs results in a massive drop in quality (as you rightly point out). You don't want to be compressing footage out of the cameras any more than you can, because you KNOW that you're going to be rescaling, retiming, wiping, fading, keying etc etc etc...

Re:Why?

[miffo.swe]

The latency problem i can understand, but that will be a problem regardless of compression or not.
Encoding and decoding will not add that much cost compared to the network.
Compressing/uncompressing only destroys the pic if its lossy. There are numerous lossless codecs that should do the trick and save tons of money in the process.

Unless you have a straight feed to your provider, your HD footage is pretty lousy compared to whats at the station. Just as we looked and awed at Zelda when it came out and had such impressive graphics, we dont see the difference until we have something to compare to.

Re:Why?

[forkazoo]

The latency problem i can understand, but that will be a problem regardless of compression or not.
Encoding and decoding will not add that much cost compared to the network.
Compressing/uncompressing only destroys the pic if its lossy. There are numerous lossless codecs that should do the trick and save tons of money in the process.

I know it isn't cool to read the headline anymore, but this is about production not watching. Yes, a frame of latency makes a big difference when you are *inside* the studio, and need to keep things sync'd to within less than a frame so that you can do live switching without flickers or delays. If you try to do live switching to take between two cameras, and you have a few frames of latency in the encoder of the sources, and the decoder in the switcher and the buffer in the switcher the sync the frames, etc., you can make the process of doing live Television appreciably worse than it is today, which isn't something anybody would spend money on. You can only sell new gear to people if the new system isn't worse than the old.

Re:Why?

[JaredOfEuropa]

You can only sell new gear to people if the new system isn't worse than the old.

Unless this new gear makes operating costs much lower. Some time ago I visited the production company that handles almost all of Dutch TV programming; these guys made the switch to an all-digital post-production system. According to them, the new (and hugely expensive) system didn't really offer any new or improved functionality, but the reduction in operational costs and time required to do post production was astounding.

Out of curiosity, what is the big deal would be with such a small latency? I can understand that in an analog system you need to keep everything synced up nicely to allow seamless switching, but in a digital system, it should be easy enough to switch between unsynced video streams. Or is the latency an issue with keeping video and audio synced up? (I can imagine that video an audio are separate streams for quite a while in the process).

Re:Why?

[psmears]

The latency problem i can understand, but that will be a problem regardless of compression or not.

The trouble is that the more effective codecs tend to require an entire frame before they can do any compression (so that they can compress more effectively by taking the whole frame into consideration). So if you have a series of pieces of equipment processing the video (camera, distribution, control desk(s), effects etc), then each one has to wait until it's received the last lines of a frame before it can even start sending out the first lines of that frame - so each element in the chain adds a whole frame's worth of latency. Whereas if you do it uncompressed, most equipment can start sending out the first line of a frame before it's even received the second line.

Encoding and decoding will not add that much cost compared to the network.

That's dependent on a lot of factors. 100Gbps Ethernet has the potential to reach much bigger economies of scale than broadcast-quality codec hardware (though it has a long way to go before reaching that far as yet).

Compressing/uncompressing only destroys the pic if its lossy. There are numerous lossless codecs that should do the trick and save tons of money in the process.

The trouble with lossless codecs is that they can never guarantee to make a frame smaller - mathematically there must be some frames that are uncompressible. Over the course of a long video, the codec will win on average, but when working with live streams, if you get just one frame that doesn't compress nicely (or worse, a few in succession) then your network has to be able to handle that bandwidth - so you might as well not use the compression in the first place.

Re:Why?

[smpoole7]

> if you get just one frame that doesn't compress nicely ... your network has to be able to handle that bandwidth

Or, your system has to *insert* latency in the form of elastic buffers to give the stream time to "catch up." Either way, your point is valid. :)

Re:Why?

[smpoole7]

> The intent here is to replace so much of the specialized cabling

Yup. I'm glad I work in radio, where we've been ferrying oversampled, high-quality audio over IP for some years now.

The digital switching and input assignments are a dream as well. Not that many years ago, if someone came into Engineering and said, "sorry, forgot! We have a paid ballgame going on at 4PM!" ... my assistants and I would literally grab a punch tool and some Belden wire and start frantically running cables. Many was the time we'd put something on air by literally throwing a pair across the floor with gaffer's tape. "Watch Yer Step!" :)

Nowadays, any source in our facility can be assigned to any input on any mixer in any control room. Run once, use many times. Ah, it's a beautiful thing. I can move an entire radio station from one control to another literally in a matter of minutes. It takes longer for the staff to physically grab their coffee cups and lucky charms than it does for my staff to move the signals.

My poor brethren in TV just have entirely too much data. If we'd all go back to RADIO drama, see, this wouldn't be a problem, now woodit? :D

Re:Why?

[drinkypoo]

Unless you're broadcasting, doesn't ethernet always require you to know the MAC addresses of the recipients ahead of time?

Re:Why?

[drinkypoo]

You can only sell new gear to people if the new system isn't worse than the old.

the new (and hugely expensive) system didn't really offer any new or improved functionality,

which does not at all address the statement that the new system must not be worse than the old.

Out of curiosity, what is the big deal would be with such a small latency?

Because it doesn't take many frames before the human eye can perceive the difference, and if you're trying to be slick you don't want any perceptible glitches. Because if you have a little latency here and a little latency there you eventually wind up with a bunch of latency.

Re:Why?

[Anonymous Coward]

Dirac Pro was made for exactly this. Latency of only 8 scanlines.

Re:Why?

[psmears]

Dirac Pro was made for exactly this. Latency of only 8 scanlines.

That's true, but to do that it has to sacrifice a lot on compression ratio (and to guarantee the latency you have to give up losslessness). That's great for squeezing, say, a 1080p signal into a channel designed for 1080i, but when it comes to having multiple 1080p streams from the different cameras in a studio you'll likely need the higher bandwidth Ethernet can provide anyway. And of course the potential market for fast Ethernet hardware is much bigger than for a codec that is only used within a particular industry - so the economies of scale are potentially much better there.

Re:Why?

[serviscope_minor]

Yes, a frame of latency makes a big difference when you are *inside* the studio, and need to keep things sync'd to within less than a frame so that you can do live switching without flickers or delays.

With causal differencng and a fixed Huffman, Golomb or exp-Golomb compressor, you can basically compress a pixel as soon as it arrives, at the bitrate of the source. Of course you'll almost certainly have to wait for the next pixel until the symbol for the previous one gets pushed out, but given that this is about going over ethernet, you have to wait to fill up a packet anyway.

As long as you're not trying to compress noise, you can usually get around a faxtor of 1.6 to 2 compression.

That's the problem, however. If you rely on that for headroom, and are watching a bunch of high frequency sources, then you might find that you've over saturated your links and have to start dropping packets which will be much worse.

It could be used with care if costs are really tight, but it's almost certainly not worth it, because of the unpredicable nature of it.

Re:Why?

[bill_mcgonigle]

and for the broadcaster to know the MAC addresses of the recipients ahead of time

Oh, jesus, are they trying to work some impossible DRM dream into an IEEE protocol?

Re:Why?

[swillden]

Nowadays, any source in our facility can be assigned to any input on any mixer in any control room.

That's the case in well-engineered TV studios as well, but they do it a different way. They have big video/audio switchers -- think about a big panel with 100 analog inputs lined up along the left edge and 100 analog outputs along the top each and wire each of the 100x100 = 10,000 intersection points and make each intersection independently activated under software control. In practice, they don't actually make switches that big, instead they use, say, 20x20 switches and then cascade them in really clever ways to simulate the 100x100 panel with far fewer actual interconnects.

Still, all of that stuff is really expensive, and the cabling required to connect every video source and every video sink to the switch is complex, expensive and just plain huge. Packet switching will make it much, much better -- when the networks can handle the data volume.

Re:Why?

[LocalH]

If you work in compressed video, then your end result will be even worse. Digital generational loss can contribute even more to the "abysmal quality of HD content" as you put it. Ideally there would only be one compression applied, and it would be before delivering to the end user. Practically, even with a fully uncompressed workflow, the best you can expect is two - one for distribution to the cable/satellite headends, and one done by the headend to fit the video signal within their bandwidth needs. Often times there may be even more depending on the requirements of program distributors.

Re:Why?

[sahonen]

In practice, they don't actually make switches that big, instead they use, say, 20x20 switches and then cascade them in really clever ways to simulate the 100x100 panel with far fewer actual interconnects.

Not sure where you get this. I've seen 256x256 routing switchers in the field, Grass Valley has a product with configurations up to 2048x2048.

Re:Why?

[swillden]

Well, I worked in this space almost 20 years ago...

Re:Why?

[sahonen]

That explains it. :D

Re:Why?

[isorox]

A summary of reasons (From the fine article):

• Dominant reason is latency. Throwing around compressed video forces latency of at least 1 frame, in an industry where latency is measured in fractions of a scan line (single horizontal line in a frame)

You'd think, but BBC R&D were claiming their DiracPro boxes introduced a latency measured in lines (like 30). I never measured it myself, and they seem to have moved to Stagebox now, with AVC-i100 as the intermediate.

Re:Why?

[isorox]

Still, all of that stuff is really expensive, and the cabling required to connect every video source and every video sink to the switch is complex, expensive and just plain huge. Packet switching will make it much, much better -- when the networks can handle the data volume.

Well huge is right, but blackmagic do a 72 in 144 out 1080i matrix for $15k.

Now if you're going for the 1000+ sources/destinations, then yet, that's still big bucks.

Re:Why?

[atamido]

Out of curiosity, what is the big deal would be with such a small latency?

Because it doesn't take many frames before the human eye can perceive the difference, and if you're trying to be slick you don't want any perceptible glitches. Because if you have a little latency here and a little latency there you eventually wind up with a bunch of latency.

This didn't really answer the question. You can time stamp every frame coming in, buffer appropriately wherever you're trying to switch between viewed streams, and things will NEVER be out of sync. Never ever. Traditional A/V types get weird ideas about how things have to work. I've help design and work with digital video storage/transmission standards, and there is absolutely no reason multiple video/audio streams should ever go out of sync.

You're never likely to be more than a frame off that you'd need to buffer. It's not like you have to decode/encode at ever station either, you decode for the viewer, but pass on the already encoded data. And even if you have to buffer at 10 different stations (for reasons I can't imagine) you'd be delaying transmission by less than a second, which inconsequential. "Live TV" is delayed far more than that by the time it reaches a viewer anyway, and it's not like anyone could notice.

Re:Why?

[atamido]

Well that's a failure of imagination. I'll admit technically speaking it often is *somewhat* compressed, - eg. 422 Subsampled chroma at least. But there is a massive difference between a delivery codec and a signal you're still working with. To start with H264 and their ilk are computationally expensive to do anything with. A single frame of 1080p is a pretty big dataset, and it's painful enough doing basic matrix transforms, but adding a bunch of higher level computations on top of that?... For example just cutting between two feeds of an inter frame compressed codec requires that the processor decompress the GOP and recreate the missing frames. Several of orders of magnitude more complicated than stopping one feed and starting another.

And generally speaking the uncompressed feed you have in broadcast situation you're doing *something* oo. Switching, mixing, adding graphics, etc. But the biggest question is one of generation loss. Even one round trip through one of those codecs results in a massive drop in quality (as you rightly point out). You don't want to be compressing footage out of the cameras any more than you can, because you KNOW that you're going to be rescaling, retiming, wiping, fading, keying etc etc etc...

H264 has vastly varying levels of compression and computational complexity. Heck, it even has lossless modes, so there is zero generational loss. And there was dedicated hardware out there years ago that could compress frames before the next frame was finished receiving. Really though, this scenario is probably better suited to one of the less complex and lower efficiency codecs, which is what the BBC is doing with the Dirac codec. And I'd imagine that a lossy codec that retained 99.9% of detail would be workable as a dozen recompressions would still leave about 99% of detail. Given the infrastructure gains, that seems like an easy win.

Re:Why?

[drinkypoo]

You can time stamp every frame coming in, buffer appropriately wherever you're trying to switch between viewed streams, and things will NEVER be out of sync. Never

Right, your solution to latency is to add more latency. Their solution is to be on time.

Re:Why?

[atamido]

You can time stamp every frame coming in, buffer appropriately wherever you're trying to switch between viewed streams, and things will NEVER be out of sync. Never

Right, your solution to latency is to add more latency. Their solution is to be on time.

The question was why does it matter, which was never answered. The GP did some hand waving about keeping in sync, which didn't answer the question. I pointed out that it didn't answer the question, and that sync isn't an issue.

Now you have managed to not answer the question, or rather say the equivalent of, "latency is important because latency". Good job.

Re:Why?

[TheSync]

BBC R&D were claiming their DiracPro boxes introduced a latency measured in lines (like 30).

I've seen a number of H.264 and JPEG-2000 contribution codecs that are under one frame of latency as well. This one claims 1ms latency.

Re:Why?

[TheSync]

Or is the latency an issue with keeping video and audio synced up?

With "embedded audio", AES pairs are mapped as ancillary data packets in the video stream, so A/V sync is not so much a problem in uncompressed.

Compression is the killer for A/V sync, because it has to split up video and audio.

Re:Why?

[danversj]

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.

Re:Why?

[danversj]

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.

Re:Why?

[isorox]

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.

Strange, cause we road cast to millions with various bits of blackmagic kit.

How many viewers do you need for a "proper studio"?

Re:Why?

[danversj]

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

Re:Why?

[atamido]

The patents/licensing issue is the reason that the BBC developed the Dirac codec. They have a few hardware boxes that they've developed that take uncompressed or analog audio/video in one end and spit it onto Ethernet on the other end. If you use those everywhere, then there are no compatibility issues. The BBC uses it right now, so it is certainly a possibility on current equipment.

I don't buy the "produced live" as an issue as you're not likely to see a full second delay at any point. Outside the studio, no one cares about a fraction of a second because everything else adds seconds of delay. Just turn on a "live" sports game on TV and the radio and you'll notice how the radio announcer is always a few seconds ahead of what you see on the TV. You would have to be filming a delayed stream in the same view as the live stream to know, and even then the delay is unlikely to be noticeable.

I could see a case where you have multiple timing planes with edits being made using circular dependencies that would wreak havoc. That sounds like more of a process issue though.

It still sounds to me like you're making the process difficult by holding onto ideas of how certain pieces have to be done, and that maybe the whole process needs to be rethought. That said, I know there are things going on that I just don't have the background to foresee or understand, so it may very well be impossible without moving around insane amounts of uncompressed data. It'll certainly be interesting to see what the next decade brings for this field.

Is the Network really the bottleneck?

[caferace]

Correct me if I'm wrong, but the bottleneck in broadcasting isn't necessarily network speeds, but dealing with the disparity in ingest formats. Loads of non-interoperable formats come in, and broadcast teams have to transcode them into something that works, and quick, especially in live mediums. 10Gbe is fine for that. It's the hardware that does the transcoding that is holding things up. Finally, there are some companies that are using GPGPU boxes to speed it up..

Re:Is the Network really the bottleneck?

[SimonTheSoundMan]

this is about live TV. Live TV is a different. The infrastructure relies on point-to-point circuit switching. One video signal is sent down one coax cable. 8 cameras is 8 coax cables, now have 1km of cable that's 8km just for the live camera feeds to the OB truck. 100GbE means one cable. 8km of coax or fibreoptic isn't cheap, and usually requires a truck and a team of sparks to transport all these cables.

Back to caferace's conversation. It is a bottleneck indeed for content that is not live. Digitising rushes to intermediate codecs takes time, tape is usually played back at normal speed or double speed, output via HD-SDI from the deck and the workstation that transcodes on the fly in realtime. Tapeless workflows speeds the process up as you can import faster that 1-2x but still takes time to transcode. However, having this slow down is not a problem, the rushes have to be logged, while they are converting this logging process can be done manually.

Cinematic filming have the workflow sorted to some extent. High end cameras shoot direct to an intermediate codec, a DIT works on set and logs as the footage is shot, and sound and continuity departments can log electronically to the same system now too. The problem at the moment is it is not one system but many have to come down to one. I work in the sound department in film as an assistant. One of my responsibilities is keeping time-code correct on set, I have to go round each department times a day* and "jam" each system, recorder, slate, camera etc so they are correctly in time so when all the data is put together by the DIT. One day they will get unified

Logging while shooting cannot be done for news or reality TV as everything happens too quick.

* Three times a day because Sony can't make a $100,000 camera that doesn't have an internal clock that doesn't drift by +/- 2-3 frames a day.

Re:Is the Network really the bottleneck?

[Anonymous Coward]

"Live TV" is only "live" in the sense that it purports to broadcast an event as it is happening. In fact, there are timing differences today between a "live" event I am receiving on an the ATSC OTA signal, HD signal over cable, and SD signal over cable. It really doesn't make a difference for the viewer if a "live" entertainment event is delayed for a second or ten to get the signals from all the sources tied together. It should be trivial to coordinate any digital signals long as the various signal sources are synced to the same timing source.

Re:Is the Network really the bottleneck?

[isorox]

this is about live TV. Live TV is a different. The infrastructure relies on point-to-point circuit switching. One video signal is sent down one coax cable. 8 cameras is 8 coax cables, now have 1km of cable that's 8km just for the live camera feeds to the OB truck.

You run co-ax over a mile?

8 cameras is 8 cores of a single fibre cable.

One of my responsibilities is keeping time-code correct on set, I have to go round each department times a day* and "jam" each system, recorder, slate, camera etc so they are correctly in time so when all the data is put together by the DIT.

I guess you don't distribute B&B + VITC then?

Logging while shooting cannot be done for news or reality TV as everything happens too quick.

It certainly can, we do it all the time on important feeds using our own system wrapped around a Quantel sQ system. EVS are particularly good at the interface for logging things like sports matches too. It's essential to log feeds that come in in realtime, otherwise you may as well throw them away.

Now getting editors to log rushes in overseas offices, where there's no librarian, and always a pressing need to move onto the next story, there's the challenge.

Re:Is the Network really the bottleneck?

[danversj]

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.

What's the point in this submission?

[Anonymous Coward]

Seriously, initially it reads like an Ask Slashdot, but it isn't because later on it doesn't ask about it but advertises a paper about it. If there's a story in there, it is well hidden in the writing.

Re:What's the point in this submission?

[danversj]

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

well written, detailed and interesting

[YesIAmAScript]

You don't see that all the time on slashdot.

Great article.

I think many are getting confused here and think that this article is about reducing the cost of producing live TV on a shoestring. The figures in this article are very high, but for professional video production, existing figures are also very high.

If you take into account that this could allow production trucks to shrink in size a bit (RG6 takes up a lot of space), the price of this new way could be even lower.

Re:well written, detailed and interesting

[Guspaz]

RG6 isn't a factor, since HD-SDI can run over fibre as well. The real savings comes from running many signals over a single ethernet cable (which at 100 GbE speeds would undoubtedly be fibre). That said, this study seems to ignore all cabling costs. It looks like their conclusions can be summed up as "An equivalent ethernet-based system has the same port costs as HD-SDI systems today, and the ethernet price will come down in the future, producing cost savings."

Re:well written, detailed and interesting

[aaarrrgggh]

Please excuse my extreme ignorance in the matter, but wouldn't it be an order of magnitude cheaper just to use MTP fiber at 10Gb and split signals rather than push everything on to a single 100Gb link?

A first step in afordable digital broadcasting

[Grayhand]

Newtek's Toaster was one of the first steps into cheap digital broadcasting. In was an all in one digital switching and titling system. There are afordable 1080P display cards finally. I ran into that problem years back when I had to edit a 1080P film. The display cards we had were high end but they still couldn't handle that much information. There are three critical elements to actually handle 2K content. Your hard drive array has to be fast enough, your busses and cabling have to be able to handle that much information then your display cards have to be powerful enough. Obviously your need fast enough processors and enough ram as well. Anyone of the elements that's not fast enough and you have a bottle neck. They might want to look into firewire networking. It's been around a long time but hasn't been widely adopted. The speed should be adequate for what he's quoting. It blows away Ethernet.

Re:A first step in afordable digital broadcasting

[Anonymous Coward]

They might want to look into firewire networking. It's been around a long time but hasn't been widely adopted. The speed should be adequate for what he's quoting. It blows away Ethernet.

I'd like to see more figures. From my research 9pin firewire will net you 800Mbps, while I use gigabit. As to do 1394 networking you are running ip packets (not quite ethernet) over firewire, I doubt the protocol would add any speed difference unless you are comparing to wireless, or have a lot of network traffic.

Re:A first step in afordable digital broadcasting

[viperidaenz]

The latest Firewire spec tops out at 3.2Gb. A single 1080p30fps video feed is 1.5Gb. Not going to be very good for routing multiple streams

Re:A first step in afordable digital broadcasting

[drinkypoo]

Newtek's Toaster was one of the first steps into cheap digital broadcasting. In was an all in one digital switching and titling system.

Yes, and it used analog sources and had an analog output, it's not until the flyer that you take steps into digital broadcasting, the toaster gave digital editing. (And, of course, there's LightWave 3D.)

They might want to look into firewire networking. It's been around a long time but hasn't been widely adopted. The speed should be adequate for what he's quoting. It blows away Ethernet.

Firewire, 800Mbps. Ethernet, 1000Mbps, costs $10 per node or so and you can now get an 8 port switch for forty bucks or something fancier with management and supporting many ports for only hundreds. And again, that's just cheap Ethernet, 10GbE is in relatively broad use now and as stated, 100GbE is around the corner.

Re:A first step in afordable digital broadcasting

[petermgreen]

It blows away Ethernet.

Do you have a source for that claim? because it seems to me you are remembering articles from the early 2000s that are no longer relavent

Afaict both firewire and modern (full duplex switched) ethernet are low overhead. So it's reasonable to compare them on the basis of their headline data rates

In the early 2000s firewire 400 was starting to appear on desktops and laptops (macs first IIRC but other vendors soon followed because of the digital video craze which at the time was firewire based) while gigabit ethernet wasn't. At this time if you wanted faster networking than 10/100 ethernet then firewire may well have been a good choice. However in the mid 2000s gigabit ethernet started to become readily available. Firewire 800 showed up soon afterwards roughly equalising things but did not see wide adoption outside of macs.

Fast forward to today, gigabit ethernet is standard on pretty much every computer sold. 10 gigabit ethernet is common in core networks of moderate sized providers though it's still too expensive for desktops or regular servers. 100 gigabit is in production with the big carriers but is still a very new thing. Meanwhile firewire seems to have stagnated (1600 and 3200 speeds exist in theory but do not seem to be available in practice) and apple (historicially it's main supporter) seems to be moving away from firewire towards thunderbolt (though they do offer an adaptor for those who want to keep their firewire gear).

It will become affordable...

[jamesh]

It will become affordable right around the time 1080p is obsolete and replaced by 10Kp (or whatever is next), requiring 1TbE networking to handle the bandwidth...

Re:It will become affordable...

[Anonymous Coward]

SDTV has another good 20 years left in it.

1080i and 1080pSF will continue to be a preferred interchange format until a serious stepchange warrants it, e.g. tele-holography.

CK.

Re:It will become affordable...

[Anonymous Coward]

From the paper

While video bandwidth requirements are increasing, Ethernet capacity is increasing at a much faster rate.

Please RTFA next time.

Re:It will become affordable...

[Zuriel]

There's more to life than pixels. Specifically, bitrate and codec. Or are broadcasters in my area the only ones who broadcast HD material that looks terrible with blockiness all over the screen whenever the camera moves?

There's a lot of room for improvement before we reach the limits of 1080p.

Re:It will become affordable...

[NJRoadfan]

How many stupid sub channels are they broadcasting in addition to their primary HD feed? All OTA broadcast stations get 6Mhz of spectrum here in the US, its just a matter of what they do with it.

There is another issue and it is a constant one

[SmallFurryCreature]

Replacement tech rarely catches up. 1080p signal? Please, that is so last year. 4k is the new norm. No TV's for it yet? Actually, they are already on sale which means that if you are not recording your repeatable content right now in 4k, you will have a hard time selling it again in the future. That is why some smart people recorded TV shows they hoped to sell again and again on film and not video-tape. Because film has a "wasted" resolution in the days of VHS video tapes but when DVD and now Blu-ray came out, these shows can simply be re-scanned from the original footage and voila, something new to flog to the punters.

I don't know how much data a 100GbE link can truly handle but the fact is that trying to catch up to currect tech means by the time you are finished, you are obsolete. the 4k standard created by the Japanese (and gosh doesn't that say a lot about the state of the west) isn't just about putting more pixels on a screen it is about all the infrastructure needed to create such content. And you better be ready for it now because if you are not, you will be left behind by everyone else.

The future may not be now, but it sure needs to have been planned for yesterday.

Re:There is another issue and it is a constant one

[zippthorne]

...the 4k standard created by the Japanese (and gosh doesn't that say a lot about the state of the west) ...

That the West is pretty great? Same as if United Kingdom or Canada created the standard. I mean, you're defining "The West" based on political and economic philosophy, not on some arbitrary lines on a map, right?

Re:There is another issue and it is a constant one

[SimonTheSoundMan]

I work in film, we usually scan 35mm 3 perf at 8k and 2 perf at 6k. Output after offline edit is usually 4k or 2k. Punters are going to be flogged re-released videos that cost the studios nothing. 1080p is more than enough for most people, unless you are going to have to have a screen large than 100 inches from 10 feet away, most people have a 32 inch TV at 15-20 feet.

TV does not work in 1080p anyway, still stuck at 1080i. Only your high-end dramas are captured with 1080p, 2k, 4k if digital (Sony F35, F65, Arri D21, Red if you don't mind downtime) or on 35mm (I haven't worked with 35mm in drama for over 5 years now).

Re:There is another issue and it is a constant one

[psmears]

I don't know how much data a 100GbE link can truly handle

It's actually very close to 100 gigabits per second. (The encoding overhead is already accounted for in the 100Gb figure, and the protocol overhead is very low: if you're using jumbo packets - and you'd probably want to - then it's easily less than 1%).

Re:There is another issue and it is a constant one

[mwvdlee]

Clearly, Japan is not a western country: http://www.justworldmap.com/maps/asia-pacific-centric-world-map-3.jpg

Re:There is another issue and it is a constant one

[kasperd]

4k is the new norm.

I tried to do the math. I don't have all the numbers, but I can still do a reasonable approximation. Assuming 8k*4k at 24bits per pixel and 100 frames per second you get 8*4*24*100Mbit/s=76.8Gbit/s. So it should be quite feasible to push a single uncompressed 4k stream over 100Gbit/s. There may very well be other issues such as what sort of hardware you need to process it, and maybe you need multiple streams over the same wire.

Re:There is another issue and it is a constant one

[Areyoukiddingme]

Having the spec is a long way from convincing fabs to manufacture it. Where is Samsung in their capital equipment depreciation cycle on their current fabs? Where are they in their current build plan? What about the other 3 panel manufacturers? Considering how FED/SED has vanished into a black hole, I think we can safely assume they're years away from running out those investments and ongoing investments.

Consider for a moment that a bigscreen OLED TV is $10,000, if you can buy one at all. They're going to milk that for the next 5-7 years, no problem. 4k, by whatever implementation, is gonna have to wait in line.

Re:There is another issue and it is a constant one

[Anonymous Coward]

Japan is "The West" because like "West Germany" it is a capitalist US client state.

Re:There is another issue and it is a constant one

[marcansoft]

More realistically, 4096 * 3072 * 60 Hz * 20 bits (That's 10-bit 4:2:2 YCbCr, like HD-SDI today) = 14 Gbit/s. You could push 6 of those streams over 100GbE.

Re:There is another issue and it is a constant one

[dave420]

There are many broadcasters the world over broadcasting 1080p over the air.

Re:There is another issue and it is a constant one

[Anonymous Coward]

No it isn't. Did you lot seriously not understand that the "what does that say about the west" was a disparaging comment? The poster was implying that the japanese are so far ahead of 'the west' and that the western state of infrastructure and tech is far behind the japanese.

Re:There is another issue and it is a constant one

[Anonymous Coward]

Who? Where? Not much use unless you tell us examples.

Re:There is another issue and it is a constant one

[drinkypoo]

Vizio came out of nowhere and drove the prices down on LCD TVs by offering televisions with a low-processing mode, contrary to what it was believed the market desired, pleasing gamer nerds who help drive purchasing decisions for friends and relatives, and anyone not too discriminating about what the final image looks like without much cash in their pocket. If any new players get into manufacturing OLEDs you'll see their price change rapidly, too.

Re:There is another issue and it is a constant one

[vlm]

Who? Where? Not much use unless you tell us examples.

No ATSC ground based broadcasters over the air in the USA. ALL the "small dish" satellites deliver 1080p "over the air" technically for pay per view, etc.

Re:There is another issue and it is a constant one

[Anonymous Coward]

>I don't know how much data a 100GbE link can truly handle

We got 98Gbps transfer rates on a 400km p2p network with two Alcatel-Lucent adapters. Plus, the 100GbE only uses one carrier wave and thus can be multiplexed in the future.

Re:There is another issue and it is a constant one

[serviscope_minor]

Who? Where? Not much use unless you tell us examples.

The BBC for one.

Re:There is another issue and it is a constant one

[cdrudge]

I can't tell on the map, are longitude lines renumbered? Or did they just stay with the international standard and rotate it around?

If you turn a map upside down, that doesn't magically make the north south, and vice versa. It just means north is in a different direction then normally expected. Likewise, re-centering the map doesn't make the far east not in the east. It's just not in the east on that map.

Re:There is another issue and it is a constant one

[Dogtanian]

That is why some smart people recorded TV shows they hoped to sell again and again on film and not video-tape. Because film has a "wasted" resolution in the days of VHS video tapes but when DVD and now Blu-ray came out, these shows can simply be re-scanned from the original footage and voila, something new to flog to the punters.

Maybe some people did, but most of them didn't. Ironically, American TV dramas from the late-80s onwards moved from being entirely shot and edited on film, to being shot on film but edited (and postproduced) on video. Standard-def crappy NTSC video, that is.

This probably didn't matter at the time, because as their primary audience was only going to be viewing the programme via an NTSC video transmission anyway. 20-25 years on, shows like Star Trek: The Next Generation look like fuzzy crap because they were done this way, and they're having to tediously re-edit and remaster the whole lot from the source footage (where they still have it) to get a "hi-def" version. Many of the effects will have to be redone because they were only ever done on SD video.

Same applies to a lot of other shows made up until the early-2000s. They definitely *weren't* planning for a hi-def Blu-Ray future. The reason those shows were even shot on film in the first place (rather than native video) is- I assume- because film-sourced footage still looks different (and more "respectable") compared to footage entirely shot on traditional interlaced video- even once converted to crappy NTSC resolution.

Re:There is another issue and it is a constant one

[Anonymous Coward]

And the reply is a disagreement.

Re:There is another issue and it is a constant one

[MikeBabcock]

To be fair, I have a 1080p projector at 10 feet from my seating position, and while there are rare occasions (mostly in video games) where I wish I had better resolutions, 1080p is still quite good enough at this distance. At 6-8' you'd definitely notice though.

Speaking of 1080i dramas, with the amount of compression artifacting I get from the limited bandwidth each show gets on satellite, I'd rather see compression improved (or higher bandwidth options) than higher resolutions for television.

Re:There is another issue and it is a constant one

[Anonymous Coward]

This applies to live, remote broadcasts. You are correct, Dish and Direct certainly broadcast video to you in 1080p. However, what is coming from the television trucks on site is 1080i at best. Also, even if you are receiving 1080p or 1080i signal to your house it is so compressed that you aren't really viewing 1080 quality. You are only going to get that from a Blu-Ray player.

People on here are really over-simplifying how remote broadcast television works. It is a very complex beast and not nearly and easy as people are making it out to be here.

Re:There is another issue and it is a constant one

[bill_mcgonigle]

something new to flog to the punters

I'm honestly curious where this phrase is used. It means as much as "something new to fish to the ketchup" to me - a verb and a noun, obviously, but I can't figure out the meaning of the words in context.

Re:There is another issue and it is a constant one

[bill_mcgonigle]

You could push 6 of those streams over 100GbE.

Why do people in this industry need 6 simultaneous unbuffered streams? TFS said that cost isn't really an issue, so a 4-port link aggregation of 10Gbps ought to be widely deployed by now if three of these streams were good enough. There are switches ($$$) that can handle that kind of backplane traffic.

Re:There is another issue and it is a constant one

[bill_mcgonigle]

At 6-8' you'd definitely notice though.

I don't think it's ever going to matter at 6-8'. 6-8cm, is probably more likely.

Re:There is another issue and it is a constant one

[bruce_the_loon]

They need it to backhaul multiple sources from studio to vision mixer. They're wanting to use 100Gbe instead of whatever super-high-def SDI type solution they're currently using that is probably distance limited. If you can trunk 4/5 camera sources over one cable instead of multiple cables, you've got a simpler infrastructure.

Re:There is another issue and it is a constant one

[kasperd]

More realistically, 4096 * 3072

They switched to measure the width of the image instead of the height? Did they think 3k didn't sound impressive enough and then named it 4k instead?

Re:There is another issue and it is a constant one

[Zerth]

If the projected screen size is greater than 45", it should be noticeable at 6-8'. If it is greater than 75", it should be obvious. You're right for 4k screens at "normal" sizes, though.

http://s3.carltonbale.com/resolution_chart.html

Re:There is another issue and it is a constant one

[swillden]

Why do people in this industry need 6 simultaneous unbuffered streams?

A typical broadcast studio has dozens, if not hundreds of simultaneous streams. Several editing suites running at once, a few people reviewing incoming feeds and selecting content from a variety of other sources, a couple of studios with 3-4 cameras each, plus actual output streams for each of the channels being produced, with large master control panels mixing the inputs to make them.

I spent a couple of years working for Philips Broadcast Television Systems (BTS), which makes equipment to run these systems. I worked on the router control systems, a bunch of embedded 68K (this was almost 20 years ago) that control big video and and audio switchers, many with hundreds of inputs and outputs (technical terms: "gazintas" and "gazaoutas"). It's unbelievable how many video and audio streams even a small studio manages, and the wiring to support it all is massive, as in foot-thick bundles routed all over under the raised floor. It makes your typical data center cable management problem look like child's play.

Besides just cabling costs, I could see packet-switched video enormously simplifying the engineering effort required to build and maintain these facilities. And it would also eliminate the need for lots of very expensive hardware like the switches BTS sold. Even with 100GbE, I'll bet large studios will still end up with cable bundles and link aggregation, but it would be vastly better than what can be done now.

Re:There is another issue and it is a constant one

[Solandri]

the 4k standard created by the Japanese (and gosh doesn't that say a lot about the state of the west)

The Japanese are gadget freaks - they were actually at the forefront of HDTV research. They were working on TVs with >1000 lines of resolution as far back as the 1970s. But their HDTV standard was analog. The advances in CPUs and DSPs allowed real-time compression and decompression of 1080i digital video at an affordable price point by the mid-1990s (my 80386 right around 1990 took ~5 sec to decode a 1024x768 JPEG). It rendered the billions of dollars Japan had sunk into analog HDTV obsolete, and the West swooped in with a digital HDTV standard which became what we use today.

So no it doesn't say anything about the state of the West. It was purely a coincidence of timing. The digital revolution happened at just the right time when Japan was reluctant to abandon the billions it had sunk into researching analog HDTV, while the West which had spent very little was free to dive headfirst into digital HDTV. Now that everything is firmly digital, it's not at all surprising that Japan is at the forefront of 4k video R&D.

Re:There is another issue and it is a constant one

[LocalH]

1080p25 (30) or 1080p50 (60)?

Re:There is another issue and it is a constant one

[ILongForDarkness]

I seem to recall from a physics experiment I did in university that the angular resolution of the eye is roughly translated at 1mm per meter distance. 10ft = ~3m. So you'd have at 1080 (assuming the 10ft is the height that you are projecting to) about 3mm per pixel. Visible at about 3m depending how good your eyes are. Of course this is "moving pictures" too not a static text/desktop display like typical computer use so will you notice the pixels quick enough before they become something else? Not sure how quickly our eyes can switch colors and still tell that it is in the same physical location down to the limit of resolution. Anyways 6" sounds about right for a clear 1080p not being good enough at a 10' projection.

Re:There is another issue and it is a constant one

[KhabaLox]

If you turn a map upside down, that doesn't magically make the north south, and vice versa. It just means north is in a different direction then normally expected. Likewise, re-centering the map doesn't make the far east not in the east. It's just not in the east on that map.

This comment led me to an interesting thought. Where does the concept (and names) of East and West come from? The idea of North and South are based on the physical properties of magnetism and the Earth's ferrous core. Did someone just decide that we need new names for Left and Right to describe other directions orthogonal to the magnetic field?

Re:There is another issue and it is a constant one

[bill_mcgonigle]

A typical broadcast studio has dozens, if not hundreds of simultaneous streams

I see, so 100Ge is primarily for 'backbone' networks then, not necessarily to each station? Or does it just make sense to switch only when the prices are really compelling vs. sorta-like-the-costs-of-foot-thick-cable?

Re:There is another issue and it is a constant one

[shmlco]

" Because film has a "wasted" resolution in the days of VHS video tapes but when DVD and now Blu-ray came out, these shows can simply be re-scanned from the original footage and voila, something new to flog to the punters."

Yes, you could rescan film for DVD. And you can (barely) rescan most film for BluRay (1080p). But 4K? Forget it.

Since lenses aren't perfect, and since many elements in a scene aren't perfectly in focus, the "information" regarding a scene actually consists of of a lot of blurry elements. (See CoC.) As such, overscanning a traditional 35mm film frame may give you more data, but it doesn't really give you all that much more actual information.

One should also note that the article mentions throwing around uncompressed 1080p data. Figure compressed data using a good codec, and 4K shouldn't be an issue at all.

Re:There is another issue and it is a constant one

[MikeBabcock]

To be fair, my screen is 103" diagonal -- the pixellation is visible at 6' at 1080p.

Re:There is another issue and it is a constant one

[swillden]

I'm not sure what you mean by "station".

Re:There is another issue and it is a constant one

[LandKurt]

The directions are based on the spin of the Earth. The concepts were there before we discovered magnetism and named the poles of a magnet after the directions on our planet. The concept of the direction east as "toward the rising sun" is pretty basic and comes out of the mists of time from proto-languages before mankind invented writing.

Calling China and Japan the East is a more recent European centric terminology. Since the planet is a globe everything is east of some other place in a relative manner. However, if you look at the land masses of Earth the largest is Asia which still puts China and Japan in the east. Only if you consider the water covered portion as the most significant would you think of Japan as an island on the western side of the great Pacific Ocean. So considering Japan the East simply shows a land centric view.

Re:There is another issue and it is a constant one

[isorox]

Replacement tech rarely catches up. 1080p signal? Please, that is so last year. 4k is the new norm.

For long form, but not for live, the glue is only just coming into realistic territory.

This year's the first year at IBC that I've really noticed 4K. NHK are still plugging their UHDTV stuff, which looked very impressive with the footage from the olympics, however I was more impressed with the 120Hz demo.

In other news, we've finally got the money to upgrade one of our overseas offices, which actually preses, from an analog matrix to a digital one. Another overseas office still has a 4:3 studio camera (with a signal chain that goes RGB>PAL>SDI>PAL>SDI>Compressed>SDI>HDSDI before pres)

Re:There is another issue and it is a constant one

[isorox]

Who? Where? Not much use unless you tell us examples.

The BBC for one.

Only p25, which doesn't count (and looks shit, bloody "film effect" idiots). 720p50 would have been a much nicer transmission standard than 1080i, but more pixels always win, in TV and in still cameras.

Re:There is another issue and it is a constant one

[isorox]

You could push 6 of those streams over 100GbE.

Why do people in this industry need 6 simultaneous unbuffered streams? TFS said that cost isn't really an issue, so a 4-port link aggregation of 10Gbps ought to be widely deployed by now if three of these streams were good enough. There are switches ($$$) that can handle that kind of backplane traffic.

For the last 15 years, our central video matrix had 1512 inputs. That was SD, but for 1080i 4:2:2 that would be 1.25 Tbit. 2.5Tbit for 1080p.

As for back plane switches, I believe a 10 year old cisco 6500 with SFM module will run with a 256gbit on the backplane.

Re:There is another issue and it is a constant one

[bill_mcgonigle]

To be fair, my screen is 103" diagonal -- the pixellation is visible at 6' at 1080p.

OK, I guess there's no inherent reason not to have a screen that takes up an entire wall either (an actual 16x9 screen would be 220" diagonal). I just think the trend will be towards personal displays over time due to the surge of mobile devices.

Re:There is another issue and it is a constant one

[bill_mcgonigle]

To be fair, my screen is 103" diagonal -- the pixellation is visible at 6' at 1080p.

bah, spazzed on the preview button... sorry for the double reply. ....

but are you actually sitting 6' from your 103" screen? That would be fairly close to immersive, no?

Re:There is another issue and it is a constant one

[mr_exit]

In film land and the visual effects industry where the 2k was standard long before HDTV was invented, it' was always a measure of the horizontal pixel dimension.

It makes sense because you would start with a 2048x1536 scan from the 35mm Frame (4/3 aspect ratio) and cut off the top and bottom to reach 2048x853 2.35:1 aspect ratio seen in the cinema. These days you also work with a mask at 2048x1152 that matches the 16:9 or 1.77 aspect ratio used in HD tv.

The delivery back to the editor is often the full 4/3 frame which gives them room to rack the picture up or down per shot. This lets them frame the theatrical release and the Bluray release slightly differently, mostly in scenes where peoples heads are near the top of frame and you want control over how close they are to the edge of frame.

 

Re:There is another issue and it is a constant one

[bill_mcgonigle]

I'm not sure what you mean by "station".

network leaf node

Re:There is another issue and it is a constant one

[KhabaLox]

The directions are based on the spin of the Earth.

Man, I feel like an idiot. This isn't a case of, "It's obvious once you hear it." It's just plain obvious.

Well, thanks for the non-condescending answer. Also, ++ on the land-centric point.

Re:There is another issue and it is a constant one

[bill_mcgonigle]

For the last 15 years, our central video matrix had 1512 inputs. That was SD, but for 1080i 4:2:2 that would be 1.25 Tbit. 2.5Tbit for 1080p.

What kind of max concurrency do you see out of those 1512?

Re:There is another issue and it is a constant one

[swillden]

Ah, yes, then. You could probably do just fine with Gig-E to most individual sources/sinks, as long as you ran them back to switches which could actually switch the full aggregate bandwidth, then 100GbE to form the internal "backbone" connecting the switches (which would need some 100GbE ports).

Re:There is another issue and it is a constant one

[isorox]

Difficult to tell, certainly over 400 though.

Re:There is another issue and it is a constant one

[TheSync]

The TV vendors went out and made 3D sets before the content producers and distributors were ready.

How many people watch 3D at home today? Not too many. The occasional 3d Blu-ray perhaps.

4K is the same way. It is being pushed out from TV vendors way ahead of a coherent strategy for production or distribution. Right now there is no 4K Blu-ray standard, for example.

That said, I believe 4K has a better chance of eventually being typical viewing in the home rather than glasses-based stereoscopic 3D which never will. But 4K being typical in the home is 5-10 years out.

Re:There is another issue and it is a constant one

[TheSync]

There are many broadcasters the world over broadcasting 1080p over the air.

According to my own sense of things and Wikipedia, there are zero 1080p/24 broadcasts in the world, even on satellite.

There are 1080p/24 video-on-demand files delivered by satellite.

1080p/24 (typically 1080p/23.98) though often used for production is kind of a special beast in the live signal broadcast engineering world. It has a tendency to break infrastructure designed around 720p/59.97 or 1080i/59.94.

Re:There is another issue and it is a constant one

[SmallFurryCreature]

1080p is enough for anyone... good luck getting to 1080p from a betamax tape.

Check the history of trying to recover old "Dad's Army" and "Doctor Who" episodes. They were recorded on tape both by pro's and amateurs. The pro's wiped theirs, the amateurs kept theirs, but it took the BBC a lot of effort to restore the amateur tape recordings to something even possible to broadcast and then it was on acceptable because it was the choice between very bad video or nothing at all.

This isn't about a show being repeated in the summer, it is about old cultural content being re-aired a decade, half a century into the future. And I am fairly confident that we will consider 1080p content hopelessly unwatchable in 50 years time.

Meanwhile, film archives that a century ago. Still watchable and gosh, that film material contains data that was lost when it was scanned for the broadcast of a TV show but now that data is still there on film for DVD, Blu-Ray and god knows what will be next. Else how do you think you got Blu-Ray Star Trek TNG episodes? Not because they recorded the shows at just the max needed resolution of the day they were made.

And where does Star Trek makes is money? In the endless re-releases. Even George Lucas went back to the film archices to get higher resolutions and he was always at the cutting edge at the tech of today.

You only record for TV format of today if your content has no value in the future.

Re:There is another issue and it is a constant one

[danversj]

Author here. In true Slashdot tradition, your comments are informed by lack of RTFA. :) In TFA, you'll note that Ethernet Link bandwidth has increased an a much faster rate than the bandwidth required by an uncompressed television signal. By the time 4k becomes common in a live-switched environment (e.g. at a football outside broadcast), we may well have Terabit Ethernet available. Ethernet, of course, is completely agnostic as to the types of data streams is distributes. Older Ethernet technology is not made automatically redunant when a newer, higher-bandwidth TV stream is introduced, it just can carry less of them. Broadcasters invest at the minimum level required to fulfill their technical licence requirements. In Australia there is still a lot of SD content being produced despite HD channels having been on-air for 10 years. It will be at least another 10 years before anything in Australia is produced and broadcast in 4k. I think the situation will be similar elsewhere. In the meantime, Ethernet will likely have increased it's link capacity 100-fold. In any case, my article is talking about Ethernet to *produce* the content, not to distribute or broadcast it.

Re:There is another issue and it is a constant one

[danversj]

100Ge would be used at the core of a production facility. All the outlying signals, such as cameras, would converge on this core. The camera feeds could then be picked off for processing and returned to the core, post-processing, then sent, in bulk (100Ge link), to a switcher / real-time-video-effects-unit (vision mixer) where the director chooses the signal to send "to air".

Re:There is another issue and it is a constant one

[danversj]

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.

Re:There is another issue and it is a constant one

[danversj]

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.

Re:There is another issue and it is a constant one

[MikeBabcock]

Seems that 10" tablets with resolutions over HD are doing just fine ... seems there's a market for those resolutions too.

"The Retina display on the new iPad features a 2048-by-1536" - http://www.apple.com/ipad/features/
http://techcrunch.com/2012/03/19/new-ipad-sales/

Re:There is another issue and it is a constant one

[MikeBabcock]

No, OP is here: http://slashdot.org/comments.pl?sid=3105099&cid=41287043

I'm sitting 10' from a 103" diagonal 1080p screen. My point was that at 6-8' it could certainly use more pixels, but at 10' it looks very good. Not perfect, but very good. I had simply failed to give the screen's dimensions at the time, which of course made my point harder to do the math on.

I do sit about 8' away when playing driving games though, with the steering wheel and my FOV nearly filled, its quite fun.

sour grapes

[cas2000]

You're just jealous because Australia is a significant source of crappy stories, and some of them are extremely low quality.

Our crappy stories per capita ratio is truly astounding.

hmmm. i should write an article about this. I'm sure I can get it published.

Re:sour grapes

[Anonymous Coward]

I can see your new low quality video now, , "Hi, my name is Ma Ma Ma Ma Ma Ma Ma Ma Ma Ma Max Headru ru ru ru ru ru oom"
Are we looking at this wrong? Maybe we should be exploiting the undocumented video effects and transitions due to apathy and shitty underpowered infrastructure? I notice the hip hop movement loves scratched discs, so much it's even emulated with software, the most successful pop vocalists, love voice damage, singing in a sewer pipe or vibrato hell?

Oh yeah on your book, maybe you should upgrade your infrastructure first.

Now, John, our beloved Prime Minister
Has an Internet stance far from love,
But he's quick with a frown if the link should fall down
While he's mailing to whitehouse-dot-gov.

He says, "Obama, I believe you've been screwing us,
You're stifling our country's success;
I would think that Australia deserves a bit more
Than thirty-two Mbps."

Tastefully stolen, slightly modded (one word), from Spammer's Paradise 2000

Re:sour grapes

[Sasayaki]

As an Australian author (book in sig)... Ow! (truth hurts?)

Re:sour grapes

[Anonymous Coward]

I agree. I find it embarrassing, especially in light of the history of this paper and the fact it was presented at SMPTE.

The problem with this article is that it does little to advance knowledge. It presents no new or original research, or even much insight. It's basic premise can be reduced down to "...it should be possible to one day replace all circuit-switched video systems with packet-switched networks." If I presented that argument to any one of my professional peers in the workplace, I would anticipate a response of, "Yeah.... and?"

For many, it is a given that broadcast systems will eventually converge on traditional networks. It happened to telephony, book libraries, and even social media. Why would silicon manufacturers such as Xilinx be marketing brand new chipsets like as the Virtex-6 for encapsulating 3G-SDI into IP if there wasn't any application for it? Why would the Standards Committee at SMPTE be working to ratify the rules of engagement on SMPTE2022-6? Why would Cisco be rushing new variants of the DCM to market that can encapsulate full video streams at baseband data rates?

'It should be possible to replace circuit-switched video platforms with packet-switched networks one day." No sh*t, Sherlock. I might as well throw in there for good measure that it should be possible to one day fly to work using a rocket-propelled backpack. What the industry really needs is some insight into the economics driving such a change, and some well-informed models and timelines on transition and implementation - you know, the types of data grounded in solid research that platform operators can actually use to plan upon.

Discussing the reliability of IP networks for mission-critical applications is simply a waste of everyone's time. IP networks are already being used in much more fail-sensitive applications like stock markets, medicine and defence. Why don't we just assume that reliability under good engineering practices is well proven and move on? The same goes for real-time applications. IP delivers delay sensitive communications for voice and video already. Problems with latency and system timing for video are already ironed out in MPEG-on-IP stacks and full frame rate videoconferencing.

The economic comparisons presented in this paper are mind-boggling. From what I can see, Table 1 and Table 2 compare the cost of contemporary broadcast equipment with the cost of various laser transceiver modules (SFP and XFP). These items are about as interchangeable as a bullet and a warship. They will still be equally as interchangeable when 2015 rolls around and breaths life into Table 3. What are you trying to tell us? You've contrasted the current cost of a video router with the forecast cost of a laser transceiver - what can I conclude from this?

My point is this - when I look at papers from technology innovators like Dell and IBM, I see sound arguments based on logic and research leading to agreeable conclusions. This paper was presented by a top engineer who works for Australia's leading provider of OB managed services to Australia's premiere broadcast conference where participants pay upwards of $1,000 to attend. All I see disjointed arguments, a bit of light commentary on contemporary practice and some superficial speculation that doesn't dig much deeper than what connectors might be seen on the back of boxes some unknown time in the future. Critical reasoning and anappreciation of the value of information seems lost.

Any the guys at SMPTE wonder why less people turn up at the conferences each year. Must remember to NOT renew my SMPTE membership.

Cheers,

Another member of the 'crappy story per capita ratio' nation.

P.S. At the risk of being pedantic, if you are going to talk about Ethernet with any presumption of credibility at a seminar where participants pay considerably to attend, please take a moment to review the OSI model and understand the differences between packets and frames. Ethernet is not a packet-switching network architecture. The appropriate PDU at layer 2 is a frame. Ethernet is a frame-switching network architecture.

Re:sour grapes

[danversj]

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

Re:sour grapes

[Broadcast_Bloke]

Hi danversj,

You make some good points.

To be clear, I'm not at all critical of anyone who brings discussion to the public sphere with the intention of simply advancing knowledge. You describe that as your intention and I think that is very noble. Your substantive knowledge of the subject matter is excellent and I believe the discussion is very well suited to forums like these.

The SMPTE submission changes things a little for me. From a commercial perspective, when I pay the significant costs to attend the seminars at SMPTE, I expect (I think reasonably) a certain level of quality in the information I'm paying for. I expect to receive information that is concrete, not rubbery; information above and beyond what is freely available on the internet; information that is properly synthesized; and a presentation free of terminology flubs. If you had paid over $1,000 for an audience seat to gather information that hopefully gives you a leading edge in the market, I think you would expect the same. For this reason, I am always very cautious about publishers and professional bodies that want to charge for access to my work. Attaching a price tag to information tends to imply a warranty for a certain level of quality. Your employer also endorsed the quality of your work by attaching their masthead and logo to the presentation. In my mind, both these things open up your work to a level of scrutiny and criticism beyond what would be fair in a healthy forum discussion. Do you agree?

You might have missed my point on the cost comparisons. At the outset, I indicated agreement that convergence into networking is almost certain. My point is that you're comparing the cost of an SDI router with a laser module. That module is like a backplane on a DA, it needs to fit into a network switch. A very, very fast one. To replace the signal distribution such as that used by your employer now (can I assume that HD1 has around 300 DA's and a 576-sq router?) you need an ethernet core switch capable of somewhere between 10-20 Tbps switching throughput. The cost of laser transceivers pales into insignifcance next to the costs for a core switch that big. They do exist though; the newest range of carrier-grade switches would be fast enough to fully replace the distribution infrastructure in a truck with 300 DA's and a 576-sq router. But the costs are wholly different to what's described in your paper, which is my point. When comparing costs, I think it's important to compare apples with apples. Would you agree? The items in table 2 are not interchangeable with the items in table 1 in your paper. Or am I missing something?

I take your point that there are still aspects (latency, QOS, etc) that need more teasing out. My personal opinion is that proper provisioning of bandwdith will overcome the need for QOS and queuing mechanisms. QOS is only useful in situations where the traffic exceeds the available bandwidth. I also think that SMPTE 2022-6 will answer a lot of the other problems. But that's just my own opinion. I give it to you for free - so it doesn't come with any warranties about quality.

Thanks for the feedback! Will you be at this months SMPTE meeting at CSIRO?

P.S. If you're serious about examining the topic in detail, have you considered enrolling in a uni research program? Having your research supervised by a uni guarantees the protection of information to some extent, so many organisations are quite happy to furnish you with sensitive information about equipment age, upgrade roadmaps, etc. Tutors will teach you how to tap into the research and resources you see as inaccessible at the moment. You'll also have access to vast library resources (think Google Scholar) and your paper will be scrutinised by professional examiners to ensure it is defensible and robust before being released to the public. Something to think about.

Re:sour grapes

[danversj]

Hi BB,

It's probably not appropriate for me to comment on SMPTE's paper approval process in this instance. I wasn't ever really told what the minimum standard for a paper was, but I did get it proofread by a number of my peers well before submitting it. Obviously I needed someone with a bit more expertise outside of outside broadcast engineering to look over it. All I will say is that your logic is sound.

Shortly after I submitted my last response I realised what you were getting at. Yes, there's more to a 100GbE switch than just the laser modules. I think the logic there was that I was starting my analyisis from a "cost per port" point of view. When I saw the price of the 100GbE laser modules I assumed (probably fatally) they were the bulk of the cost of the switch, and that the other parts were insignifigant from a cost perspective. I don't think the overall conclusion was wrong (timescale perhaps out by a few years), but yes, there are errors in my working it out. Looking back, and with the benefit of your criticisim, it would have been better to write it as an opinion article rather than as a research paper.

So - my opinion on another of your earlier comments - The nature of the outside broadcast business is fast turnaround, and that requires that many technical aspects be "plug and play". Another of the reasons I tend to favour Audio Video Bridging is that it presents itself as a "plug and play" approach to QoS, VLAN and other networking aspects. The promoters of the standard(s) specifically mention that very little networking knowledge is required to deploy an AVB-enabled network. I'm not aware of the particulars, but the 802.1ak standard hopefully should allow for things like multicast trees, spanning tree, VLANs, etc to be automated to a large degree by being established on an "as needed" basis. Indeed, a packet/frame-switched system is pretty-much useless to us outside broadcasters unless these things can be automated. Also, topologically speaking, a single outside broadcast facility resembles a single LAN. I would not expect anyone working at an OB to need or have knowledge of routing protocols at all. While we require expensive, high-bandwidth equipment, I don't see the need to make the network more complicated than it needs to be.

I do find the idea of a uni research program interesting. I will be attending the SMPTE meeting at CSIRO where I'm sure we'll discuss this further.

Cheers,

Dan

1080p for TV?

[Anonymous Coward]

I bought a Blu-ray player last year. After buying a few movies in the blu-ray format, I just wasn't impressed with the difference in quality to upgrade my DVD collection (granted that nearly all of them are old films and would require expensive restoration processes). I use internet TV catchup services from time to time which is in youtube quality format and see no difference in quality when watching on my 32 inch LCD TV. For me, DVD quality on both mediums suits me. When you look at most TV content, is there a need for HD quality video? Would reality shows benefit from HD? Even if you look at average big-budget drama, there isn't that much scope for long location shots where it would simply look better on HD. I would say that the only TV content that would benefit from HD is sport and nature programmes.

Use 10Ge and channel bonding

[Anonymous Coward]

For end devices 10Ge already has the bandwidth, and is available now. There is 40Ge if you really need some extra speed.

10Ge runs over CAT6 something 100Ge may never do. But I don't know why CAT cables are desireable when low latency is the aim.

For switch to switch links channel bonding will give you as much bandwidth as you need.

Waiting for 100Ge for lan traffic seems to be a waste of time and opportunity.

And why is broadcasting circuit switched?

[Anonymous Coward]

Because it needs quality of service. Something ethernet has historically shunned.

100GbE

[Anonymous Coward]

That's 1x10^11 copyright lawyers per second for those who don't know phy.

Professional Broadcasting

[JumboMessiah]

Insightful write up. Getting rare here on ./

For those not RTFA, they are referring to using Ethernet in professional live broadcast situations. Aka, newsroom or outdoor sporting broadcasts where cable bundles are still common. I believe they are imagining a world where a broadcast truck rolls up to a stadium and runs a few pair of 100Gbe fiber vs a large coax bundle. This could save considerable time and money. Some interesting bw numbers:

SD 270 Mbit/s
Interlaced HD 1485 Mbit/s
Progressive HD 2970 Mbit/s

Re:Professional Broadcasting

[DerekLyons]

I believe they are imagining a world where a broadcast truck rolls up to a stadium and runs a few pair of 100Gbe fiber vs a large coax bundle.

I don't see how that's cheaper - because the cost of labor is the same, regardless of what's under the cable jacket. The OP is also missing the difference between the one-time cost of the hardware, and the ongoing costs of... well, pretty much everything else.

Re:Professional Broadcasting

[Anonymous Coward]

Sorta... Ethernet tends to get cheaper. As there are many uses for it. Point to point video feed has 1 maybe 2 uses.

What do I mean? Simple as others start using it you can buy off the shelf hardware. I can buy the same switches as the guy running a datacenter is running. Instead of going to a specialty boutique hardware manufacture. Make it a software problem and you can do a lot more...

The labor involved is probably a wash. Or could even trend downward as instead of having to hire a guy who knows how to run p2p audio/vid cable you can get a IT sort of guy who can do more ...

Re:Professional Broadcasting

[MikeBabcock]

And just as they get their 100GbE put in, they'll be trying to upgrade equipment to handle 4k resolutions instead ...

Re:Professional Broadcasting

[danversj]

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

Price is a little inaccurate...

[Anonymous Coward]

The $55k item linked in the description is the price of one CFP module .. and you need 2 - one for each end. Then you need the line card to plug the CFP modules into, those will run you about $250k. Then you need the chassis/supervisor modules to plug the line card into (plus the power supplies/etc).

100Gb is VERY expensive :) Reassuringly expensive.

Re:Price is a little inaccurate...

[danversj]

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.

10 GigE should be enough for most situations...

[quetwo]

In the last studio upgrade we did, we retrofitted everything with Ethernet -- 10G switches. Cameras are all ASI -> GigE (MPEG-2 Multicast), switchers, and final outs.

Uncompressed, at full rate, an ASI feed uses 380 MB/s. An uncompressed 1080p melted feed is 38 MB/s.

You need to do careful network planning, but remember these are switches -- you shouldn't see traffic you didn't request. Right now we usually have about 8 cameras, plus the mixer, plus the groomer, plus the ad-insert. It then goes right out via the internet (Internet2 -- FSN is also a partner so we can send right to them), and a satellite truck as a backup. Our plan next year is not to have the satellite tuck on site anymore.

This is for a live-sports studio that feeds about 300 cable / satellite providers, reaching about 73M homes.

Re:10 GigE should be enough for most situations...

[ibennetch]

In the last studio upgrade we did, we retrofitted everything with Ethernet -- 10G switches. Cameras are all ASI -> GigE (MPEG-2 Multicast), switchers, and final outs.

So do the switcher and routers take in the MPEG stream, or you convert back from the GigE to HDSDI or ASI video?

It then goes right out via the internet (Internet2 -- FSN is also a partner so we can send right to them), and a satellite truck as a backup.

Sounds like what we do (private IP-based network to distribute to our partners), but the GigE stuff in house sounds fascinating.

The problem with Ethernet is

[Anonymous Coward]

You can't guarantee things come out in the same order you put them in, or with nice predictable latency between point A and B. Not much of a problem for shifting shed loads of data between servers but it sure is when your piping live uncompressed video to your head-end.

Re:The problem with Ethernet is

[Anonymous Coward]

Please RTFA, they have a whole section dedicated to the latency issue.

From the article

The Institute of Electrical and Electronics Engineers (IEEE), publishers of the Ethernet standard (IEEE 802.3) has created the Audio Video Bridging (AVB) Task Group to work on standards to "provide the specifications that will allow time-synchronized low latency streaming services through IEEE 802 networks".[15][16][17]

Re:The problem with Ethernet is

[Anonymous Coward]

Low latency doesn't mean no latency, or even known latency, nor does it address the FIFO issue. There's a reason places like commercial radio stations still use T1 lines for their tower uplinks.

Re:The problem with Ethernet is

[Anonymous Coward]

Once again, just go RTFA before complaining the paper doesn't address your problem X, Y or Z.

Re:The problem with Ethernet is

[Anonymous Coward]

I didn't say the paper didn't address my problem, I said ethernet is unsuited to critical real time streaming applications due to non-constant latency and packet order problems, this is true of anything that can reasonable be called ethernet regardless of protocalls in use, how much bandwidth headroom you have, how lightning fast your switches are or whatever other steps you might take to emolliate the problem.

Re:The problem with Ethernet is

[Anonymous Coward]

anything that can reasonable be called ethernet

That's why they're extending the ethernet protocol with the AVB extension. If you had RTFAed, you'd know AVB extends the ethernet protocol itself rather than sitting on top of the ethernet protocol. If you think AVB is insufficient, say so and explain why. At least some items in your list are addressed by AVB (guaranteed and predictible maximum latency). Or is our beef that ethernet with AVB capabilities doesn't count because it cannot be reasonnably be called ethernet?

Miscitation?

[phizi0n]

For reference, a typical video production switcher, the Grass Valley Kalypso HD, has an autotiming window of +/- 6 microseconds in 1080i/60 mode[14]. This means that source video signals received by the switcher must be synchronised to within 12 microseconds of each other. That is, the start of each frame of video from each video source must be received within 12 microseconds of a frame from any other video source in the switcher.

In citation 14 I don't see any mention of 1080i/60 autotiming. In table 10 and table 33 it lists several delays and the 1080i/29.97/30 autotiming is +/- 6.16 s but 1080i/60 should be even lower if it were supported.

Re:Miscitation?

[danversj]

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

Ethernet or TCP/IP?

[Anonymous Coward]

Quoth the article: "Ethernet’s 'natural' or designed tendency in its basic form is to slow down all traffic flows to enable fair bandwidth sharing if the medium becomes saturated with traffic. It also has guaranteed delivery mechanisms whereby lost packets are retransmitted."

uhhh

Re:Ethernet or TCP/IP?

[danversj]

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.

lots of wasted bits in SDI

[mozumder]

Raw sensor frames only need 14-16 bits per pixel, with the added bonus of increased dynamic range.

IT and Broadcast TV Is not CS it's more trade

[Joe_Dragon]

IT and Broadcast TV Is not CS it's more trade like and needs lot's hands on skills with the equipment.

Re:IT and Broadcast TV Is not CS it's more trade

[danversj]

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

I predict a drop in reliability.

[Above]

Network Architect here, who's worked on many varied systems. I predict what the consumer will see is a drop in reliability.

Real time communication is just that, real time. Gear of old (5ESS switches, TDM networks, Coax analog video switchers) were actually built around this notation from the ground up, and many design decisions were made to keep things operating at all costs. Of course, this added cost and complexity.

Packet based networks were built on the assumption that losing data was a-ok. Packet drops are how problems are signaled. Protocols are just barely in some cases starting to figure out how to properly deal with this for real time situations, and largely the approach is to still throw bandwidth at the problem.

So yes, running one 100Gbe cable will be cheaper in the future, but it's going to introduce a host of new failure modes that, no offense, you probably don't understand. Heck, most "Network Architects" sadly don't understand, not knowing enough about the outgoing or incoming technology. However I've seen the studies, and it's not pretty. VoIP is not as reliable as circuit switched voice, but it's pretty darn close as it's got more mature codecs and low bandwidth. iSCSI is laughably unreliable compared to even fiber channel connections, much less some kind of direct connection methodology. The failure mode is also horrible, a minor network blip can corrupt file systems and lock up systems so they need a reboot. Of course, it's also a straight up redundancy thing; when you're covering the Super Bowl having every camera feed leave the building on a single cable sounds like a great cost and time reducer, until it fails, or someone cuts it, or whatever, and you lose 100% of the feeds, not just one or two.

With the old tech the engineering happened in a lab, with qualified people studying the solution in detail, and with reliability as a prime concern for most real time applications. With the new tech, folks are taking an IP switch and IP protocol, both of which were designed to lose data as a signally mechanism and who's #1, #2, and #3 design goals were cheap, cheap, and cheap and then multiplexing on many streams to further reduce costs. The engineering, if any, is in the hands of the person assembling the end system which is often some moderately qualified vendor engineer who's going to walk away from it at the end. It's no wonder when they fail it's in spectacular fashion.

I'm not saying you can't move live TV over 100Gbe (and why not over 10Gbe, even 10x10Gbe is cheaper than 100Gbe right now), but if I owned a TV station and my revenue depended on it, I don't think that's the direction I would be going...

Re:I predict a drop in reliability.

[Anonymous Coward]

I don't think they'd ever have something as large as the super bowl on a single line, anyway as always it's understanding the technology and designing for failures. There is a lot of live TV that doesn't have 30 million people watching it at once that would benefit from reduced cabling and costs. The engineers that you're talking about are expensive and there simply isn't enough of them for the amount of information produced daily. Use your high paid team where it matters and save costs elsewhere. I'm not disagreeing with what your saying, it's just that cheap wins in the end.

Re:I predict a drop in reliability.

[Anonymous Coward]

You didn't read the fine article before you produced this rant, did you? This is not about taking some Off-The-Shelf 100GbE switches and just networking them together in a best effort network like a traditional IP over ethernet network. Instead, it's about a bunch of new protocols and standards that are intended to reserve bandwidth and shape traffic and synchronize the devices so that you get a reliable TDM connection between multiple Devices with multiple streams over just one cable.

To learn a little more about AVB we're going to look at its four facets in detail: IEEE 802.1BA Identification of Participating Devices; IEEE 802.1Qat Admission Controls; IEEE 802.1Qav Traffic Shaping for AV Streams; and IEEE 802.1AS Precise Synchronization.

Re:I predict a drop in reliability.

[Anonymous Coward]

As a Broadcast Engineer with 22 years experience, the 'Above" poster has nailed the issue.

Re:I predict a drop in reliability.

[Jeremi]

Packet based networks were built on the assumption that losing data was a-ok. Packet drops are how problems are signaled.

This is where AVB comes in. With AVB the data-sender is required to pre-reserve the necessary bandwidth across all switches from one end of the data path to the other, and the switches then make sure that the bandwidth you reserved is available for your packets to use (by holding off non-real-time traffic if necessary). By this method it is guaranteed that (short of hardware failure) no packets from your real-time video feed will be dropped. And if it's hardware failure you're worried about, you can set up a redundant network topography.

AVB does require that all switches along the data path be upgraded to be AVB-aware, of course.

Re:I predict a drop in reliability.

[Above]

I did, and I saw that part.

I worked on ATM networks in the past, which had resource reservation that first did not work the way anyone who used it expected, and second was turned off (well, ignored, really) in any operating network I ever saw because when push came to shove and the network had to be upgraded or oversubscribed, oversubscribed won every time.

I worked on MPLS networks, with resource reservation that had the exact same issues as the ATM networks, recreated anew with an "updated" protocol. While I've seen a few more networks using it, in every case engineers have also hand worked around it due to both limitations in the protocol and business realties.

I worked on VoIP that used resource reservation protocols, and in every single case once operational realities came into play it was found to cause problems and resource reservation was removed.

Resource reservation is not a new concept in packet based networks. It's been around at least 25 years that I know of, probably longer. These new "protocols and standards" are rehashing old ideas. The problem is they flat out don't work. To get the same reliability as TDM, it turns out (more or less) you get the same efficiency as TDM. Since folks were upgrading to packet to increase efficiency, this is almost never good enough.

Also, I will guarantee you that the switches will be using off the shelf silicon. They will take standard ethernet chips from the usual set of vendors and the only thing new here will be some custom software to speak these new protocols and configure the queues on the chips. These protocols will be poorly tested in the real world, since they only apply to broadcast TV, which is a niche application.

Re:I predict a drop in reliability.

[TheSync]

I'll add that at least one major network uses IP contribution video from NFL statidums (JPEG 2000 at 100 Mbps). Evidently it works, but they and the stadiums are on-network with the same provider.

Re:I predict a drop in reliability.

[danversj]

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).

Numbers seem VERY wrong

[Controlio]

HDSDI uncompressed video is 1.5Gb/s. That is the standard for moving uncompressed video around inside a TV truck, whether 720p or 1080i. It rises to 3Gb/s if you're doing multiple phases of video (3D video, super slo-mo, etc). Within that 1.5Gb/s is still more than enough headroom to embed multiple datastreams and channels of audio (8 stereo pairs is the norm, some streams do up to 16). So I fail to see why 100Gb/s is necessary to transmit uncompressed video.

It's also a chicken-and-egg scenario. I'm a broadcast engineer and audio specialist. I had Ma Bell contact me about 7 years ago asking about how important uncompressed video transmission was, as they were trying to gauge a timeframe for a network rebuild to allow for uncompressed video transmission. My answer hasn't changed much in 7 years, because although moving uncompressed video from site to (in the case of Fox) Houston and then back to your local affiliate would be nice, it's completely unnecessary because by the time it reaches your house your local cable or satellite operator has compressed your 1.5Gb/s signal down to between 4Mb/s and 10Mb/s typically, making the quality gains negligible.

It will solve one problem, which is image degradation due to multiple passes of compression. Think about it... the 1.5Gb/s leaves our TV truck and gets ASI compressed into 270Mb/s (best case scenario, satellite transmission is significantly lower bandwidth, and most networks don't use an entire 270M circuit, they use less). It then arrives at the network hub, where it gets decompressed. If it's live it then goes through several switchers and graphics boxes, then gets re-compressed to ASI and sent either to another hub or to your local affiliate. (If not live, it gets put into a server which re-compresses the video even harder before playout.) Your local affiliate then decompresses it, it passes through more switchers and graphics boxes, then it gets either broadcast using 8VSB, or it gets re-compressed and passed on to your cable or satellite provider, who then un-compresses it, processes it into MPEG or some other flavor, and re-compresses it into its final 3-12Mb/s data stream for your receiver to decompress one final time.

This would eliminate several compression steps, and mean a better final image quality because you're not recompressing compression artifacts over and over and over again. A real 1.5Gb/s video frame looks like staring out a window compared to the nastiness you see when you hit pause on your DVR during a football game (also a best-case scenario, most cable/broadcast/sat providers ramp up the bitrate to the max for live sports and then set it back down shortly thereafter).

But the 100Gb/s makes no sense to me. Are you (crazy) overcompensating for latency? Are you sending 100% redundant data for error correction? Why in the world would you need that much overhead? I can't imagine it's to send multiple video feeds, the telco companies don't want you to do that because then you order less circuits from them. Plus you'd want at least two circuits anyways in case your primary circuit goes down for some reason.

(Side note: The one benefit to a TV truck using Ethernet as a transmission medium is the fact that these circuits are bi-directional. Transmission circuits nowadays are all unidirectional, meaning you need to order more circuits if you need a return video feed, meaning higher transmission costs. The ability to send return video or even confidence return signals back down the same line would be huge for us and a big money saver.)

Re:Numbers seem VERY wrong

[av-grunt]

A couple of comments:

"It's also a chicken-and-egg scenario. .... because by the time it reaches your house your local cable or satellite operator has compressed your 1.5Gb/s signal down to between 4Mb/s and 10Mb/s typically, making the quality gains negligible."
-It's not a chicken/egg scenario. It's Garbage in/Garbage out. That's why you start with a Higher bandwidth signal to allow the codec more numbers to compress (more info) which will allow for a better, finer final compressed product.

"It will solve one problem, which is image degradation due to multiple passes of compression."
-No. The only product I am aware that handles multi-generational video compression compensation is the MOLE product from Snell and Wilcox.
http://www.broadcastpapers.com/whitepapers/MPEG-2-CLONING-USING-MOLE-TECHNOLOGY.cfm?objid=32&pid=100&fromCategory=49

"... gets ASI compressed into 270Mb/s (best case scenario, satellite transmission is significantly lower bandwidth, and most networks don't use an entire 270M circuit, they use less).
-No. ASI is a Transports stream that clocks at 270Mb/s and you can Multiplex many MPEG2/4 bitstreams inside of it. That's how we serve 2 HD and 3 SD channels over one line to our Transmitter.

" It then arrives at the network hub, where it gets decompressed. If it's live it then goes through several switchers and graphics boxes, then gets re-compressed to ASI and sent either to another hub or to your local affiliate. (If not live, it gets put into a server which re-compresses the video even harder before playout.)"
-Yes/No. Source Video from Satellite, Tape, ASI over Fiber is De-muxe'd and De-coded,(now the video is uncompressed) and then re-ingested into that facilities Video Servers and compressed/stored at their "house" standard. (Typically MPEG2@40Mb/s for HD, MPGE2@15Mb/s for SD. ) If it's files based video, it is FTP'd to a Xcoder and transcoded to the house standard and stored on their Video Servers(Omneon, GVG, Harris, etc.) ..

"re-compresses it into its final 3-12Mb/s data stream for your receiver to decompress one final time."
-Correct.

"This would eliminate several compression steps, and mean a better final image quality because you're not recompressing compression artifacts over and over and over again."
-Again, this has been solved. (see Snell) No one adopted it. No one will until it makes business sense.

" (also a best-case scenario, most cable/broadcast/sat providers ramp up the bitrate to the max for live sports and then set it back down shortly thereafter)."
-Correct. Talking heads get 3-4Mb/s MPEG2 where as sports/NASCAR (high motion, high color) get 9-12Mb/s, and that's after pre-processing usually.

"But the 100Gb/s makes no sense to me. Are you (crazy) overcompensating for latency? Are you sending 100% redundant data for error correction? "
-Agreed. Ethernet was never designed for a Live swtiched signal. It's a game of how much risk you are willing to accept in a packet based world. It is possible, with FEC (Forward Error Correction) that this can be acheived though. See SMPTE-2202 parts1&2
https://secure.connect.pbs.org/pbsdocuments/Solutions/Conferences/Technology/2011/Presentations/Whitcomb_Real-time_Professional_Broadcast_Signals_Over_IP_Networks.pdf

"Plus you'd want at least two circuits anyways in case your primary circuit goes down for some reason."
-Absolutely necessary. In fact, typical Primary feeds are done over SAT and backup is done over Fiber on the ground.

Now, with respect to the Article.

Can schemes be developed to make an Ethernet Switch act like an un-compressed Switched Circuit Digital Video Router.
Sure. With enough cache, bit-rate, and internal packet routing intelligence, I believe it can be solved.
(Via hyper fast FEC, you could solve all packet loss's. ie. I can move 100 times faster then a normal human being, therefore, I will catch that person from falling before they even begin to fall or know they are fall

Re:Numbers seem VERY wrong

[TheSync]

Your local affiliate then decompresses it, it passes through more switchers and graphics boxes, then it gets either broadcast using 8VSB, or it gets re-compressed and passed on to your cable or satellite provider, who then un-compresses it, processes it into MPEG or some other flavor, and re-compresses it into its final 3-12Mb/s data stream for your receiver to decompress one final time.

The FOX Broadcast Network encodes in MPEG-2 once at the uplink site, and stations use stream splicers between the local MPEG-2 encoder and the satellite MPEG-2 feed. During network time, the compressed feed from the network goes bit-for-bit over the satellite, through the affiliate splicer, to the transmitter over the air to the end viewer.

Unless of course you are watching on cable or satellite, in which case it is usually decoded and recoded in MPEG-2 or H.264...

Re:Numbers seem VERY wrong

[danversj]

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.

Already here

[Anonymous Coward]

My company is doing 100GE client interfaces. Tell the router guys to drop the prices, the transport layer is in, and most providers are upgrading or in the planning stage to support it.

Will there be superjumbo frames?

[swb]

Out here in the hinterlands, nobody will invest in 10GbE yet, but do any of these support larger jumbo frames? I see about 92xx as the largest supported frame size for 1 GbE with most equipment only accepting 9000.

Do the jumbo frame sizes make a 10x leap when the data rate does? Or at least the 6x jump from standard to 9k that 100Mbit to 1Gbit was?

I suppose there are reasons why they wouldn't (maybe 900k or even 325k frame sizes are too much, even at 100GbE), but it seems that if there's some efficiency benefit for 1GbE to use jumbos, you'd think there would be some reason to jack it up when the data rate jacked up.

Re:Will there be superjumbo frames?

[petermgreen]

Really there are two reasons to increase maximum frame size. One is to improve efficiency on the wire, the other is to reduce the number of forwarding descisions to be made.

With improving efficiency on the wire you quickly get into diminishing returns. With 9000 byte frames your header overhead (assuming a TCP/IPv6 session) is probablly of the order of 1%. Reducing that overheard further just isn't going to buy you much more thoughput.

Reducing the number of forwarding decisions would be a legitimate reason to go to larger frames. However given that the main market for high speed ethernet gear is ISPs the vendors have to design their equipment to run at full speed with the packet sizes typically used on the internet.

Bufferbloat for latency

[Anonymous Coward]

Assuming we are not only talking about Ethernet but also about TCP/IP another consideration for the networking gear is bufferbloat (http://gettys.wordpress.com/bufferbloat-faq/) in all the components. I'd assume that will be a difficult thing to account for in anything but the routers and workstation hardware. But then it might not be an issue so much in cameras, etc.

Forget ethernet, get Infiniband

[Pegasus]

It's cheaper, faster and available today. Check out www.mellanox.com - newest dual fdr cards are especially nice.

Re:Forget ethernet, get Infiniband

[colin_faber]

Agreed, though any manufacture would be fine here so long as it supports OFED. Ethernet and worse, TCP/IP over Ethernet is technology of the past. Yes it works, but the overhead is HUGE and the performance isn't.

it's british slang

[Chirs]

read it as "market to the consumers"

Re:post you own paper day on /.

[danversj]

Yep! It's me! :)

Unsuitable for SMPTE conference presentation

[Broadcast_Bloke]

This article makes for an interesting forum discussion. But it's poor quality in its original intention. It was presented at a leading Australian trade show where participants paid upwards of $1,000 to attend. It was subsequently published in an Australian trade magazine.

My issue with this article is that it does little to advance knowledge. It presents no new or original research, or even much insight. It's basic premise can be reduced down to "...it should be possible to one day replace all circuit-switched video systems with packet-switched networks." If I presented that argument to any one of my professional peers in the workplace, I would anticipate a response of, "Yeah.... and?"

For many, it is a given that broadcast systems will eventually converge on traditional networks. It happened to telephony, book libraries, and even social media. Why would silicon manufacturers such as Xilinx be marketing brand new chipsets like as the Virtex-6 for encapsulating 3G-SDI into IP if there wasn't any application for it? Why would the Standards Committee at SMPTE be working to ratify the rules of engagement on SMPTE2022-6? Why would Cisco be rushing new variants of the DCM to market that can encapsulate full video streams at baseband data rates?

"It should be possible to replace circuit-switched video platforms with packet-switched networks one day." No sh*t, Sherlock. I might as well throw in there for good measure that it should be possible to one day fly to work using a rocket-propelled backpack. What the industry really needs is some insight into the economics driving such a change, and some well-informed models and timelines on transition and implementation - you know, the types of data grounded in solid research that platform operators can actually use to plan upon.

Discussing the reliability of IP networks for mission-critical applications is simply a waste of everyone's time. IP networks are already being used in much more fail-sensitive applications like stock markets, medicine and defence. Why don't we just assume that reliability under good engineering practices is well proven and move on? The same goes for real-time applications. IP delivers delay sensitive communications for voice and video already. Problems with latency and system timing for video are already ironed out in MPEG-on-IP stacks and full frame rate videoconferencing.

The economic comparisons presented in this paper are mind-boggling. From what I can see, Table 1 and Table 2 compare the cost of contemporary broadcast equipment with the cost of various laser transceiver modules (SFP and XFP). These items are about as interchangeable as a bullet and a warship. They will still be equally as un-interchangeable when 2015 rolls around and breaths life into Table 3. What are you trying to tell us? You've contrasted the current cost of a video router with the forecast cost of a laser transceiver - what can I conclude from this?

Why don't you try a more useful comparison, like contrasting the cost of contemporary SDI distribution with the equivalent ethernet-based distribution. Take a medium-sized broadcast plant that has a 576-square router and 300 distribution amplifiers. This computes to a total of 3,976 video flows. For 1080p, you would need a switch fabric that can sustain 11.9 Tbps of non-redundant throughput (plus overheads and other traffic). The good news is that such beasts do exist. Wheel in the Cisco Nexus 7000. It's designed as a carrier-grade backbone switch, and it's fast. BSkyB use it for core switching in the Harlequin building. It can provide 768x 10Gbps ports and a total fabric throughput of 17.6 Tbps. It is a real subsititute for an SDI router and ten frames of DA's, and you can buy one right now. You'll probably want two though, for redundancy. Allow a million dollars each, plus spares and support and you'll be in the ballpark. The total solution is still 4-5 times the price of an SDI router and DA frames, before purchasing a single camera, monitor, processor or piece