[opendtv] Re: 4:3 transmissions of syndicated programming
- From: Craig Birkmaier <craig@xxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Tue, 4 Mar 2008 11:44:28 -0500
At 11:01 AM -0500 3/4/08, John Shutt wrote:
I did not say that, Craig. Mixing HD and SD is extremely easy to do.
We have an Omneon server with a MultiPort 4102. This gives us two
channels of HD-SDI out and automatically upconverts SD clips to HD.
It also has two SD ports that automatically downconverts HD clips.
The HD spigots always have HD and the SD spigots always have SD.
Very easy. We also own Evertz
Thanks for the correction. This still raises an issue. Do you always
use an HD format for emission. upconverting any SD content?
I thought You were doing SD multiplexes most of the time? Is there
ever the need to switch a sub-channel to a different resolution?
The problem that I was outlining, and the question that Bert was
asking, is specifically what do we do with SD material in an SD
server or on videotape (yes it's still used) that could either be
4:3 or ANAMORPHIC 16:9? Without a standard and reliable way for
each SD clip to be tagged as 16:9 anamorphic or 4:3, (let alone get
into AFD which is yet another can-o-worms,) nothing downstream from
the server can automatically adapt for it.
The information is SUPPOSED to be in the MPEG-2 transport stream
header. Apparently this is not the case.
The proper place for integration is the receiver in the TV or STB.
I could not disagree more with you, Craig, because every single
receiver would have to have the same dual decoder configuration and
cache server, and not a single manufacturer even added a second
Dolby Decoder for mixing audio, let alone expecting every single
receiver to include hard drives for caching.
I guess this is more of a philosophical issue, as clearly there is a
huge installed base of receivers that could not do this. BUT...
If broadcasters, or a subset thereof, decided to create a new
platform, which IMHO will be necessary for them to survive, they
could do this.
A simple example. There are two big problems with MPEG compression.
cross fades and fades to black. These functions can easily be
implemented in a receiver with dual decoders.
Those two functions cannot be implemented in a receiver with dual
decoders. For the cross fade example, you have to be sending two
full bandwidth video streams for the cross fade, doubling your bit
overhead. For the second example, an advanced codec with a "fade to
black" tool is much simpler than dual decoders.
Yes they can. You only need a few seconds of both streams - this can
easily be accommodated in the buffers for each decoder without
burdening the channel. You could even send the overlap frames well
ahead of the transition when the stat mux says there is room.
You're stuck in the "one large set top box for the living room"
model of what a receiver should be. Receiver/decoders should be as
simple and cheap as possible, so that they can be included in as
many items as possible. What you propose means that a cache server
must be included in every single device that has an ATSC tuner.
That's the prevailing opinion, just as it it the prevailing opinion
that broadcasters need to maintain program continuity on any
channel/sub-channel. I would only point out that millions of people
are watching TV shows that are file based today, not a carefully
constructed linear stream. The linear stream concept will probably
persist for the one FTA channel that broadcasters must provide. All
of the rest of the bits can be delivered as file, which could also be
viewed as streams if you happened to tune it at the right moment. But
it is more likely that viewers will "subscribe " to content and watch
it asynchronously as we move into the future.
And what happens if this local cache server isn't preloaded with the
correct spot? I'm channel surfing, and I tune to your station just
before a break. I haven't been tuned to your channel for the last 10
minutes, so I didn't receive a trickle stream feed to my cache
server of the next break. What does my box show? What if I was the
one that purchased a spot in that break from you and I expected to
see it?
No problem. You still maintain continuity in the linear channel. They
just see whatever you are inserting at the station. When I ran master
control more than three decades ago, we would on occasion do a
network roll-over to cover something or to provide a localized
version of a commercial. You could think of an ad inserted by a STB
as a roll-over.
Agilevision was adopted by many PBS stations. The bitsplicing model
held promise, but Agilevision flopped because it was hugely
expensive, less-than-robust piece of equipment that combined master
control switcher, video server, EAS, CG, branding, and audio mixing
all into one box, and that box failed too often. Individual
replacement hard drives for the server system cost more than an
entire new PC. PBS users have a less than kind euphemism for the
Agilevision.
And those were only part of the issue. Commerrcial broadcasters were
deathly afraid of putting a box into their facility that could
essentially replace them. Fox network had huge push-back on the local
insertion boxes that they required affiliates to install.
The Agilevision box was accepted by PBS affiliates because it more
closely matched their business model. But, as you said, the box
failed to deliver on its promise.
The problem is that broadcasters were not, and most still are not,
ready to break away from the linear program thinking that they have
been using for nearly six decades.
No, the problem is one of asymmetry. One expensive broadcast
facility and millions of cheap receivers. Your model is one of
slightly cheaper broadcast facility and millions of much more
expensive, large, and complex receivers.
My model resembles what is happening in the real world. The Internet
is driven by a distributed server model much like what a broadcast
facility will become. And it DEPENDS on intelligent, connected
clients to assemble the content in the receiver.
This is why I keep saying that broadcasters must reinvent their
business model to survive. The networks are ALREADY making the
transition to Internet delivery of their content. The programs
contain SIGNIFICANTLY less commercials and the commercials that
remain can be targeted to the viewer, just as Google is doing today.
It could work in a closed system such as DBS or Cable, where you
control the number of receivers authorized, and can fill a local
cache server no matter what channel they are tuned to. But it would
never work in a market full of independent OTA broadcasters and
fickle channel surfing viewers.
We disagree. The Internet does not rely upon collaboration between
the operators of the millions of channels of content that are
delivered daily. It's all based in the standards that they can expect
a web browser to support. Except for Microsoft, that is, which based
much of their business model on selling servers, authoring tools and
browsers that use Microsoft's secret sauce, which won't work on
competing browsers.
Regards
Craig
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
