[opendtv] Re: ATSC and Lip Sync
- From: Craig Birkmaier <craig@xxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Sun, 31 May 2009 10:39:03 -0400
A few general comments about the lip sync problem.
The reality that TV stations typically run their on-air operations to
produce a continuous stream at digital baseband, then encode it for
emission, does NOT make this the most desirable practice for an all
digital broadcast system that uses headers and descriptors to deliver
multiple synchronous and asynchronous services.
It is a matter of convenience, and a legacy practice that has been
propped up by manufacturers who are designing to what broadcasters
perceive as necessary, rather than designing for a modern digital
media infrastructure with significantly enhanced capabilities.
To be fair, the ATSC standard was conceived largely to replicate the
practices used for legacy analog broadcast systems. The standard does
not support a variety of capabilities that are better handled in an
"intelligent receiver." In the long run, this fact alone may be the
downfall of broadcasting, as significantly enhanced capabilities
become commonplace with new digital media appliances that pull
content from the Internet.
If you are confused, consider a very simple capability that 'could"
have been implemented at the receiver level, but instead is handled
in the broadcast master control mixer. That capability is graphics
overlays onto program content; this includes, logo bugs, emergency
warning messages, and commercial tags that may be inserted live,
rather than creating multiple versions of a spot on the server to
deal with tag rotations.
The log bug problem is particularly relevant. Where do you inset the
bug on a 16:9 program stream? If you put it in the lower right
corner, it will not be seen on legacy 4:3 displays that crop the
program rather than presenting it in letterbox. If the bug is
inserted by the receiver, it can be placed in the proper location all
the time, and a receiver manufacturer could allow the consumer to
turn the damn things off.
This is a no-brainer - Web browsers routinely do this, with full
support for transparency. And all types of receivers need local
graphics capabilities today for navigation, program guides, etc.
I could go on and on, but I think everyone may get the point that
putting intelligence in the receiver - or at the edges of the network
if you prefer - can significantly enhance the capabilities for the
entity that is sending the bits to the receiver.
TV stations SHOULD be sending multiple streams that can be composited
in the receiver. This can solve all manner of problems with entropy
coding, and will allow for mass personalization of the broadcast
experience, rather than mass sameness. This can include localization
of information and commercials to sub markets, personalized
commercials, and transitions in the receiver that will overcome the
limitations of entropy coding...
Can you say Fade-to-Block?
Consider the audio sync problem for a moment. If EVERY event was a
new stream, rather than the concatenation of multiple event, it would
be quite easy to get the lip sync correct for each event - other than
some of the "production" issues raised by Mark, which are "upstream."
In short, it's time for broadcasters to start thinking bout
delivering files rather than streams. And if we REALLY want to
improve delivered quality, these files should be properly encoded and
delivered without additional decoding/re-encoding. As an program
supplier or an advertiser, I would very much like to guarantee that
the bits delivered are the same bits that I provided to the
broadcaster.
As we move deeper into the new digital media world, there will be
other opportunities to fix problems in innovative ways. Real-time
(and near real-time) image processing and analysis are now making
their way into commercial software products. Some of you may have
seen the Apple "I'm a Mac" commercial where PC is trying to sort
photos - the Mac guy points out that iPhoto now offers facial
recognition software that can find all instances of a particular
person.
How hard could it be to analyze a live video stream and look for
natural pauses and lip movement to adjust lip sync? Stuff like this
will happen!
So in conclusion, I must ask Cliff, why he thinks it is the
responsibility of the FCC to guarantee things work? Obviously we have
a brain dead digital broadcast system because the brain dead FCC
rubber stamped a standard created by a handful of industry insiders
with one goal in mind:
To produce $ billions in ongoing royalty streams for technologies
that should have been in the public domain that are now hopelessly
dated.
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:
