Has anyone else noticed that transitioning to file-based digital media has now made workflow analysis a top priority? If I can quote Andy Rooney, "Why is that?" I think the primary reason is that the traditional broadcast workflow doesn't make sense in the file-based environment...or does it? Well, it depends on how you look at your broadcast plant and the mission of your organization. When it comes to evaluating workflows, a couple of the fundamental questions to ask are, "what is our business?" and "is it still relevant?"
If your business is being a carrier of content primarily created by others, than you are in essence a repackaging operation, which in the multi-stream world, is highly commoditized and therefore requires a very lean organization to be sustainable.
A network-affiliated station, relying on advertising revenues from the network stream and syndicated components to pay the bills and then relying on revenues from its local news components for profitability, may see some real challenges. As the non-local products increase in their availability from other sources and the audience migrates to those sources, it is highly unlikely that the advertising revenues will keep pace with the increase cost per viewer that will result from audience dilution.
The author and his tools
In this environment, the underlying technical plant has to be fully automated, highly reliable and inexpensive to operate and maintain. I think in essence you're looking at a facility that is actually driven by the traffic department, not by engineers or operators. As far as I know, the companies that are making traffic systems don't really want the responsibility of taking direct control of the automation that is running the content on the air. But, without that seamless connection, there will need to be an interface layer that verifies that what traffic is sending and what automation is playing agree.
Now on the other hand, if your business is about creating local content, then the underlying technical plant has to be capable of efficient operation without getting in the way of the creative process. This may or may not sound easy but I have seen and quite frankly been involved in projects that failed because the intuitively designed technology made sense to the designers and engineers but not to producers and users.
Some of my colleagues at various PBS stations have been discussing how to handle audio at the broadcast station with the soon to be implemented CALM Act. One of the discussion threads has been about implementing proper metadata when using Dolby E. I'm not complaining about Dolby E or any Dolby product but a few of the comments pointed back to producers not ensuring that the metadata on their Dolby E encoded content was correct. A few of the producers at my facility and some others I talked with all knew the name Dolby and the term metadata. Some had even heard of Dolby E. None of them knew anything about the metadata required for ensuring that the audio was properly encoded or decoded. More importantly, none of them wanted to know about audio metadata. For most producers, metadata is the stuff they used to write on the tape label, the box and on their story notes. They know and understand this metadata because it is useful to them in the creation of their content. This techno-geek metadata is at best a non-issue to them and at worst, a reason not to use the systems or services that requires it. That is not to say that producers won't learn new technologies or systems, but for the creative person it appears that they have to want to learn it rather than have to learn it.
So when designing a workflow in the content creation realm, we need to understand that there are times when the lowest price may not be the most strategic decision. Early in my tenure at IPTV, all of the IT staff was moved into my department and one of the dividing lines was the familiar Mac/PC boundary. Since the vast majority of the station was PC based, I decided that whenever possible we would purchase PC versions of software. I made that decision because I was looking at the complexity of managing and servicing the systems used throughout the station. It took several years and the patient understanding of a couple of editors and a few IT people who were all willing to try. We finally got to the point where it was clearly proved that I was completely wrong in trying to implement this strategy. Having spent time with editors and IT professionals, I realized even though the software could be implemented on both platforms, there were time when it just ran better and was easier to implement on a Mac and the cost savings didn't make up for the differences.
ASSEMBLY LINE VS. CUSTOMIZED
I think most stations are really more hybrid operations based on my analogy. They have this distribution factory that repackages parts from others and they have this "skunk works" that turns out specialty parts (content) that has a premium price compared to the wholesale price they pay for the outsourced parts. So when planning digital workflow it is vital to understand the different requirements between the two. Using the automobile industry as an analogy, think about the different mindsets, processes and budgets required for turning out a custom car vs. a production model. Which is the right business model? Are you working for an assembly line facility that turns out a low cost stream? Are you working for a custom shop that turns out premium components? Are you working for a hybrid operation that does both? There is no right or wrong answer, it is just important to recognize and understand the differences. That way you can design the workflow to be realm appropriate.
I'll share one last analogy from my own life. Not counting my family, I have two things I love; technology and music. I enjoy exploring technologies, understanding them and using them. I enjoy playing music, figuring out songs and learning to play better. I have a complete love/hate relationship when I try to combine the two.
My music room is littered with sophisticated guitar effects multi-processing pedals that feature unlimited creative possibilities. Most of them I use for three or four setups because they are too complex to program and when I am in the creative realm things need to flow. Having to figure out how to activate the flanging effect or turn off the echo-plex disrupts the flow and hinders my creativity. However, when I am in my technical realm and am noodling around with these effects just to hear what they sound like, I'll spend many happy hours experimenting.
The difference in the latter realm is that I want to do it. I don't think it is too different for the people that create the content we broadcast, they live and work in two parallel realms and move between them happily at will and begrudgingly when forced.
Bill Hayes is director of engineering for Iowa Public Television.
The latest product and technology information
Future US's leading brands bring the most important, up-to-date information right to your inbox
Bill Hayes, director of engineering and technology for Iowa PBS, has been at the forefront of broadcast TV technology for 40 years, 23 of them at Iowa PBS. He’s served as president of IEEE’s Broadcast Technology Society, is a Partnership Board Member of the International Broadcasting Convention (IBC) and has contributed extensively to SMPTE and ATSC. He is a recipient of Future's 2021 Tech Leadership Award.
Thank you for signing up to TV Tech. You will receive a verification email shortly.
There was a problem. Please refresh the page and try again.