Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Guess Who Holds the Keys to 4K Television and Broadcast?

So you are saying that the cost of the file transfer ( $ / GB ) or tape stock is only a fraction of the total transfer cost ?

If so, of course.
 
... The one constant, however, is SR tape, because that's a stable format that offers both broadcast formats, has a very good history in terms of reliability and robustness, and a proven codec. It's survived because it represents the physical asset that can be put on a shelf, used directly, or used for quick retrieval of entire programs or parts of programs. ...

There is another thing SR Tape has going for it. It plays EXACTLY the same in every single SR deck. There are no gamma shifts, color level changes, etc. You can't say this about the current state of file based delivery. A lot of times what looks good in the sequence looks different when played via the media player--there are even differences between players, e.g. Qucktime Player vs VLC, Then you can get into videocard overlay issues, verision and driver changes. It can be one big mess. On the other hand, you stick in an SR tape, you know exactly how it will look.
 
There is another thing SR Tape has going for it. It plays EXACTLY the same in every single SR deck. There are no gamma shifts, color level changes, etc. You can't say this about the current state of file base delivery. A lot of times what looks good in the sequence looks different when played via the media player--there are even differences between players, e.g. Qucktime Player vs VLC, Then you can get into videocard overlay issues, verision and driver changes. It can be one big mess. On the other hand, you stick in an SR tape, you know exactly how it will look.

Thats true for an SR deck, its also true for an LTO tape. Its only true so far as the SR deck is concerned up to the BNC on the rear of the machine and assumes is correctly lined up. What happens to either data stream down the chain is entirely another thing. File based delivery is perfectly fine but in the same way as you would police standards using say an HDSDI chain you also police them using a file based data chain. An SR deck is just a data recorder at the end of the day and I've not yet seen a 4K SR deck but I have seen 4K and 5K on LTO and it repeatable for replay.
 
But Instrumental to the SR deck workflow is the SR codec. It always compresses and decompresses the same way. Using other codecs and file-based wrappers, you can have a host of problems, e.g. blacks can get crushed, colors levels shifted, gamma changed. And it's hard to track down if the problem is with the encode, decode, wrapper, player, export settings... or who knows what.
 
But Instrumental to the SR deck workflow is the SR codec. It always compresses and decompresses the same way. Using other codecs and file-based wrappers, you can have a host of problems, e.g. blacks can get crushed, colors levels shifted, gamma changed. And it's hard to track down if the problem is with the encode, decode, wrapper, player, export settings... or who knows what.

Yes thats true but it's also true of other codecs. Its more likely to be the player at fault. I can point you at all sorts of HDSDI kit that can cause processing issues and also doesnt account for any ajustments being out of correct alignment in the signal chain. Either workflow can be good or badly operated. For the most part Data is just Cheaper, Better, Faster when is used properly.
 
Yes thats true but it's also true of other codecs. Its more likely to be the player at fault. I can point you at all sorts of HDSDI kit that can cause processing issues and also doesnt account for any ajustments being out of correct alignment in the signal chain. Either workflow can be good or badly operated. For the most part Data is just Cheaper, Better, Faster when is used properly.

As long as you stay away from Quicktime, I would largely agree. If you're using Quicktime, all bets are off. In fact, I would go further and say that in general, the open source implementation of Quicktime, included as part of ffmpeg, has far fewer anomalies than Apple's software and is a lot more reliable in terms of image stability and fidelity - and that includes the recently released open source version of ProRes. Apple seems to think they know how everyone is going to use and view their files, and so they put in automatic adjustments based on their assumptions. The problem is that the assumptions are not only often wrong, but they are inconsistent. "Automatic" adjustments are made but only on certain codec/player combinations. This leads to a lot of inconsistencies and problems, especially when using their most popular codecs for this industry, namely ProRes and H.264. Peter is absolutely right in that you can't count on Quicktime playing back a file the way it's intended, and you can't count on it being the same on all hardware.
 
So you are saying that the cost of the file transfer ( $ / GB ) or tape stock is only a fraction of the total transfer cost ?

If so, of course.


I guess I was reacting to what I thought was a bad message, that everything that has to do with files or the Internet doesn't have a cost, or has a significantly lower cost by definition. That has never been the case, and it's not really the case now. What has changed is that given unlimited time, deliverable products can be made by individuals on desktop equipment and sent to other places via the Internet on relatively cheap connections. But in network television, that's usually not the case, in part because there isn't unlimited time (there's usually almost no time), there are very strict technical and thus QC requirements, there are very tight security issues, and the files are often large. Not to mention the storage requirements for program material prior to the creation of the deliverable element and through post production, which needs to be accounted for because it's not a cost that can often be passed directly to the client. I'm not saying the facility model is the only way to post a television program - far from it, and I think that model is going through severe changes and in many cases is being replaced completely. But however you look at it, whether a show is being posted in a facility built for the purpose or in a cutting room of the production company, there are real costs involved that need to be covered. Storage is not free, space is not free, people are not free, and bandwidth is not free. When something is described as "cheap", the question should be "compared to what?", not simply a dollar figure. Saying what something "should" cost requires knowledge of what it actually takes to create and distribute it. These days people seem to pull numbers out of thin air when they're talking about these subjects, based on nothing other than perhaps the cost of groceries and gas. I'm not saying you did that, but costs are real and the numbers that are arrived at are not based on simply creating enormous profits. In fact, I would argue that the post production business in general is one of the lowest margin businesses in the industry and has been for a long time. And although it's not as capital intensive as it once was when telecines were necessary (at about $2 million each), significant infrastructure is still a requirement, regardless of how you look at it.
 
The reality for file based transfer to work, it's going to require a delivery format to be established JUST LIKE HDCAM-SR or DCP.

A file container that has in built error checking, can only accept specific content, has tracks and channels for your different deliverable standards, and always conforms to standards every time.

The difficulty with that, from a Vendor point of view, if you develop and deliver this built for purpose deliverable format - how do you ensure uptake, and how do you make a return on investment for those development costs?

Here's something RED knows all about - they obviously pour money into REDCINE-X PRO because it helps sell cameras. But a delivery standard that is file based and does all of the above doesn't sell hardware, it sells computers, and the video engineering experts like those at Sony with the experience and expertise to develop such a standard don't make money from the sell of computers, they make money from the sale of turnkey hardware that does it's job exceptionally well - just like RED does on the camera side, and one imagines they are planning to on the delivery side with RED RAY.

And, compared to DCP. tape based delivery very much follows a "If it ain't broke, don't fix it" model.

DCP made sense because 35mm delivery WAS broken. Shipping was costly, storage was costly, films degraded AS THEY WERE PLAY BACKED. DCP suffers none of those flaws and introduced added benefits.

Comparatively HDCAM-SR as a tape is actually file based delivery, it's just files in that it's digital data, in a specific forma, in a specific codec, on a specific medium. Sony is introducing a solid state version - hopefully this will prove this point further.

Replacing tapes with drives, or a disk image that can be uploaded online, doesn't change the reality of what needs to be delivered be it SD, HD or 4K, and it doesn't change the level of error checking and the need for realtime encoding and playback as a MINIMUM starting point to work with current workflows. And not realtime playback on some machines, but not others, realtime playback and full error checking EVERY TIME it's played back, from every machine that can play it.

4K delivery will need not just a codec, but a container and delivery method that can fulfill these same needs, and ideally ONCE it reaches those standards, additional useful things like added meta data, indexing for search etc can be added on top of that to create added value for the media stored in that format. But until there is something that fulfills the role of something as well as HDCAM-SR tape based delivery does, it's pointless to point to a future being held back by the incumbents (be it the ridiculous idea that it's Avid, or the slightly less ridiculous idea that it's networks or Sony or those who have provided the best infrastructure.)

The future is being held back by a lack of alternatives that do the job as well, or better, whether more costly or less. And if they aren't being supplied, chances are it's because even though those companies could do it, it's very hard to figure out how to make money out of it.

Maybe RED RAY will provide that solution - but the fact that Mike Most has to clarify his thoughts in regards to the needs of a broadcast world to Stuart to avoid talking at cross purposes doesn't yet fill me with hope that it will be.

I am sure it will be a START toward a solution - but I'll be very surprised if it is delivered as an ecosystem that works for broadcast, and until SOMEBODY delivers that eco system, all the 4K tv's in the world won't change the question marks when it comes to deliverables.
 
The future is being held back by a lack of alternatives that do the job as well, or better, whether more costly or less. And if they aren't being supplied, chances are it's because even though those companies could do it, it's very hard to figure out how to make money out of it.

I completely agree about the lack of viable, robust alternatives to videotape at this point in time. But if we're to use the DCP as an example - and it's a very good one - what's needed is not likely to come from a company, or even a group of companies. It is likely to come from an industry consortium, which is exactly how the DCP came about. It is likely that such a solution would embrace open formats and codecs, just as the DCP does. In short, the ultimate answer is probably a broadcast equivalent of the DCP, which is exactly what was proposed a few years ago as a Digital Video Package. The problem is that since there is already a working system, based primarily around SR videotape, there is not a lot of incentive to come up with something else unless it's considerably better. In the film distribution and exhibition world, there was a lot of impetus to implement a digital alternative to film distribution, which is what led to the creation of the DCI by the major studios, which developed the DCP. In other words, they were creating something that didn't yet exist in any real acceptable form. Television is a different story, so for an industry initiative to occur that might come up with the file based alternative, everyone has to agree that it's necessary. I'm not sure the industry is at that point yet.
 
... 4K delivery will need not just a codec, but a container and delivery method that can fulfill these same needs, and ideally ONCE it reaches those standards, additional useful things like added meta data, indexing for search etc can be added on top of that to create added value for the media stored in that format. But until there is something that fulfills the role of something as well as HDCAM-SR tape based delivery does, it's pointless to point to a future being held back by the incumbents (be it the ridiculous idea that it's Avid, or the slightly less ridiculous idea that it's networks or Sony or those who have provided the best infrastructure.) ...

Craig, I agree with the entirety of your post.

The point I was making about Avid is that their products have to confront the issues you mention. Avid has to be more thoughtful/careful/slow w/ 4K b/c MC, Symphony and NewsCutter have traditionally worked with the entire Avid infrastructure--and that includes broadcast. These products also work with other makers' broadcast products as well.

So Vegas, Premiere and FCP can have any frame size, codec and wrapper they want. The other NLE makers can remain detached from questions that need to be asked, issues that need to be addressed and problems that need to be solved before 4K broadcast can move closer to becoming a reality. Avid is not in that position.

But of course, if at NAB Avid releases a quad-HD project size, 4K DNxHD and a roadmap for 4K implementation, it's not going to cause broadcasters to embrace 4K. They are going to make decisions that they believe make economic sense for them; that goes without saying.

But it's also true that w/o 4K Avid, 4K broadcast isn't happening. And it's not simply a matter of having an appropriate project frame size. For 4K Avid to happen, a lot of the technical issues you and others have brought up must have been worked out to a significant degree.

And I do believe that the lack of an Avid 4K solution besides DS makes it imminently easier to ignore 4K broadcast.


INT. NICE OFFICE --DAY

NEWBIE
Hey, it looks like online delivery guys are targeting 4K, let's look into it too.

EXECUTIVE
Do we have a way to work with 4K?

NEWBIE
No.

EXECUTIVE
Can we buy a way?

NEWBIE
No.

EXECUTIVE
Upgrade?

NEWBIE
No.

EXECUTIVE
Thanks.
(under his breath)
Dumbshit.
 
As long as you stay away from Quicktime, I would largely agree.

I would follow Discovery's lead with DPX sequence, WAV Audio with MD5 sum check.

I also quite like what Cineform are doing but its is proprietary.

Id be interested in view but perhaps this is the wrong thread.
 
To answer your question, I would say Red holds the keys! with their codex. Fullstop.
 
Sony has already expanded the SR codec to work with 4K. There is also an SR-Lite version that's only 220Mbs at 1080. These are based on MPEG-4 SStP. It seems that Sony is working very hard to position itself as the provider of the codec and storage technology that becomes the "HDCAM-SR tape" for 4K and file based workflows. BTW, they also make a 4K hardware upconverter for 2K material.
 
Sony has already expanded the SR codec to work with 4K. There is also an SR-Lite version that's only 220Mbs at 1080. These are based on MPEG-4 SStP. It seems that Sony is working very hard to position itself as the provider of the codec and storage technology that becomes the "HDCAM-SR tape" for 4K and file based workflows. BTW, they also make a 4K hardware upconverter for 2K material.

So long as it exists in the world of data then that would be another possible option, perhaps it could be resolution independent too. What we need rid of is proprietary video tape.
 
So long as it exists in the world of data then that would be another possible option, perhaps it could be resolution independent too. What we need rid of is proprietary video tape.

It is resolution independent.

I don't understand your point about "getting rid of proprietary video tape." As a mastering format, there is nothing in the data world that is more immediately available, more convenient, more robust, or quite frankly more cost effective than SR videotape at this point in time. Just as there is nothing more useful, more robust, or more immediately available than film for long term storage of features. The professional industry doesn't operate on the same rules of "cheaper is always better because I as an individual can afford it" than the indie feature and individual artist world that is largely represented on RedUser. In the studio level television world, SR tape is universally supported, available just about everywhere, totally portable, has no compatibility issues, and is very cost effective for mastering and storage. The cost of the machine is a non-issue.
 
It is resolution independent.

I don't understand your point about "getting rid of proprietary video tape." As a mastering format, there is nothing in the data world that is more immediately available, more convenient, more robust, or quite frankly more cost effective than SR videotape at this point in time. Just as there is nothing more useful, more robust, or more immediately available than film for long term storage of features. The professional industry doesn't operate on the same rules of "cheaper is always better because I as an individual can afford it" than the indie feature and individual artist world that is largely represented on RedUser. In the studio level television world, SR tape is universally supported, available just about everywhere, totally portable, has no compatibility issues, and is very cost effective for mastering and storage. The cost of the machine is a non-issue.

In the world I come from the cost of any device is an issue and SR is a relatively expensive format but thats not the reason Id prefer not to use it. I completely agree that cheaper isn't always better. Handling with media within a data environment is a much more flexable means of handling content both in the high end Professional institutions and also smaller independent companies. Post systems are virtually all data environments these days and most play out centres are virtually all data servers too, and in our country all most backed up on to LTO. I think the move to deliver in a data format is a good move, why go to a video tape based format when you don't need to. I mentioned programme delivery via DPX sequences was a step in the right direction in my view but I respect YMMV. I read some where recently about hockey quote, I don't recall the exact words but its along the lines of, Don't go to where the puck was, go to where the puck will be. I think its applies here too.
 
Sony has already expanded the SR codec to work with 4K. There is also an SR-Lite version that's only 220Mbs at 1080. These are based on MPEG-4 SStP. It seems that Sony is working very hard to position itself as the provider of the codec and storage technology that becomes the "HDCAM-SR tape" for 4K and file based workflows. BTW, they also make a 4K hardware upconverter for 2K material.


And Panasonic has a competing 4K resolution I-frame codec based on H.264, so there won't be an issue of finding a codec and tape transport that can record 4K 10-bit RGB. However I wonder if broadcasters want a video codec of that data rate if they are moving to IP based program delivery...
 
I think the move to deliver in a data format is a good move, why go to a video tape based format when you don't need to.

I don't have any problem with file based deliveries, in fact I look forward to it. What I don't want to see, however, is a free for all of multiple codecs, some of which are proprietary, and a need to constantly transcode between them because the industry couldn't get it together to come up with some standards. The data based video world is littered with more codecs and formats than there have been tape formats over the years - and there have been a LOT of tape formats. Quality control becomes a lot more of an issue when everyone wants something different. One thing about SR delivery is that this problem doesn't exist, so standards and quality control are rather simple to maintain. That's why I'm not one to say it "needs" to go away quite yet. But at the same time, as I said, I have no problem with file based deliveries...

I mentioned programme delivery via DPX sequences was a step in the right direction in my view but I respect YMMV.

DPX sequences? Really? For broadcast delivery? That seems to me to be a step backwards in terms of convenience, reliability, simplicity, and just about everything else. I honestly don't see the need for an uncompressed format for program delivery in 2012, not with the excellent codecs now available. As Jim Jannard has been fond of saying for the last 5 years or so, compression is not a limiting technology, it is an enabling technology. If we were to adopt file based deliveries based on something like DPX files, we're being extremely wasteful of resources, both in terms of storage required, and the time to copy the files and transport them. Compression technologies like JPEG2000 and even DNxHD and Prores shrink those requirements down to a much more manageable size, allowing sensible electronic delivery in a reasonable length of time, and with fewer files to keep track of. I like using file sequences for post production because they yield a great deal of flexibility in terms of replacing only specified frames, or replacing individual corrupt frames without having to recreate an entire movie file. But once it gets to the point of delivery, I really don't see the logic of having resources that are at least 4 times larger than they need to be. But, as you say, YMMV...
 
MPEG-4 is an open standard. This does not mean it is standardized.

I've been able to count 12 different MPEG-4 encoders and 14 decoders. Now many of these are not in wide use. But still, there seems to be more than one way to encode and decode MPEG-4; some choices are x264, Mainconcept, ffmpeg.

So having an open standard does not equal having a uniform way of encoding and playing-back a file that makes it look the same no matter how or where it is recorded or displayed.

Open standards invite ongoing tweaking by a worldwide community. This is great for innovation, but is it great for a professional standard that requires complete uniformity? So while Sony's HDCAM-SR is based on the open standard MPEG-4 SStP, SR itself is not an open standard.
 
I don't have any problem with file based deliveries, in fact I look forward to it. What I don't want to see, however, is a free for all of multiple codecs, some of which are proprietary, and a need to constantly transcode between them because the industry couldn't get it together to come up with some standards. The data based video world is littered with more codecs and formats than there have been tape formats over the years - and there have been a LOT of tape formats. Quality control becomes a lot more of an issue when everyone wants something different. One thing about SR delivery is that this problem doesn't exist, so standards and quality control are rather simple to maintain. That's why I'm not one to say it "needs" to go away quite yet. But at the same time, as I said, I have no problem with file based deliveries...

DPX sequences? Really? For broadcast delivery? That seems to me to be a step backwards in terms of convenience, reliability, simplicity, and just about everything else. I honestly don't see the need for an uncompressed format for program delivery in 2012, not with the excellent codecs now available. As Jim Jannard has been fond of saying for the last 5 years or so, compression is not a limiting technology, it is an enabling technology. If we were to adopt file based deliveries based on something like DPX files, we're being extremely wasteful of resources, both in terms of storage required, and the time to copy the files and transport them. Compression technologies like JPEG2000 and even DNxHD and Prores shrink those requirements down to a much more manageable size, allowing sensible electronic delivery in a reasonable length of time, and with fewer files to keep track of. I like using file sequences for post production because they yield a great deal of flexibility in terms of replacing only specified frames, or replacing individual corrupt frames without having to recreate an entire movie file. But once it gets to the point of delivery, I really don't see the logic of having resources that are at least 4 times larger than they need to be. But, as you say, YMMV...

I think we are of the same opinion about this. I would much prefer file based but standards have to apply or as you rightly point out we will be in a whole heap of a mess or the current multitude of codecs will continue to prevail. There needs to be an agreed standard here and Im not sure who is going to propose and implement it ? I an also see a time when a broadcaster may require a high quality file based Master for reporposing and future versioning and also hand the task of creating a seperate deliverable for their play out servers, say Omnion, GV or whatever, as part of the deliverables.

The DPX suggestion came about as a suggested starting point only as Discovery have it in their specs for some 3D content so it is already in use. But yes I agree theres nothing wrong with compression when its done right and some thing else would be better to move on to. Given a clean slate for file based delivery what standard and codec would you use and what means if any of sum check ?
 
Back
Top