[opendtv] Re: ATSC and Lip Sync
- From: Tom Barry <trbarry@xxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Sat, 30 May 2009 13:17:18 -0400
Those are all valid problems which should be acknowledged, openly
discussed, and then solved. There are obviously some trade-offs but I
think no show stoppers.
I'm usually of the opinion that if enough people complain then money
gets thrown at the problem and a (compromise) solution will emerge.
And one of the nice things about digital TV is that it is possible for
most anybody to capture the whole stream and analyze it or repeatedly
and reproducibly play it back in a number of different ways. Thus it is
usually possible to point out where someone may or may not be doing
something wrong.
I'm a little surprised that stations don't just record their own digital
broadcasts 24/7 for this and other purposes in handling complaints from
both consumers and advertisers. At about 8.5 GB/hr a standard 1.5 TB
hard drive (< $150) could hold a whole week of 24/7 broadcast recording
as the entire 19.39 mbps stream. Swap them on Sunday nights and reuse
after a few weeks.
Generally though I don't think many problems will get solved until the
public is actually relying on digital TV. If they try it and bitch
about it this is good. If they just avoid it but don't say anything
this is bad for the industry.
- Tom
PS - If splicers are purposely hiding discontinuity flags in order to
make it harder to sense commercial breaks I could see where this could
add to the problem for some receivers.
Mark Schubin wrote:
>
>>> Cliff Benham wrote:
>>>
>>>> IT SHOULD JUST WORK. PERIOD.
> Would that it were that easy. Here are a few scenarios:
>
> 1. A program on storms is showing lightning strikes. They are
> probably being shot from pretty far away. Should they deliver true
> lip sync, which would involve the crack occurring perhaps seconds
> after the flash, or should they fake it?
>
> 2. A conscientious broadcaster is airing a remote feed via a frame
> sync, with a matching audio delay. Eventually, the frame sync's
> buffer will fill and need to be reset, should the audio follow,
> causing an audible pop, or should it wait, out of sync, until a pause?
>
> 3. A TD/vision mixer is doing an interesting effect, involving
> pictures passing through several effects systems, each adding a field
> of video delay. Should the audio mixer delay the audio to match? If
> so, what should happen when the TD/vision mixer cuts from the effect
> to the live camera and suddenly loses the video delay? Should the
> audio pop, should it be out of sync during the effect, or should there
> be some transition period, again waiting for a pause?
>
> 4. A wireless camera is being used as one of many in a show, and its
> encode-decode processing adds latency. Is it better to delay the
> other dozen cameras and the audio to match, introducing multiple
> points of failure (and cost) and adding to the director's reaction
> time? Is it better to delay the audio only when the wireless camera
> is used? If so, what about split screens or other effects? And what
> about getting in and out of the audio delay?
>
> 5. A TV show is being presented in a large movie theater. Should the
> lip sync be correct for someone in the front row? In that case, it'll
> be a frame out for someone roughly a dozen rows back.
>
> 6. A news show involves a three-way conversation among people at
> great distances. Is it better to have perfect lip sync or to avoid
> adding to the conversational delay?
>
> Those are just a few issues that don't lend themselves to a "IT SHOULD
> JUST WORK. PERIOD" solution.
>
> Then there are many situations that DO lend themselves to a simple
> solution that is simply not being done: frame-rate conversion without
> compensating delay, Dolby E or AC-3 coding without compensation for
> both encode and decode delays, etc. I would love to see those wiped
> out through training and, perhaps, the expenditure of a little money
> (audio delay capability is built into many audio consoles these days,
> and in post it can just be slewed).
>
> And then there are consumer decoders -- not just ATSC, but also cable
> and satellite (I don't have any telco-video home experience, so I
> can't speak to theirs). They can lose lip sync even when the
> broadcaster does everything right. I share your frustration, and I
> applaud your complaint, but I'd like to direct it appropriately.
>
> By all means, send a complaint to the FCC about not requiring frequent
> PTS synching in receivers. I point out merely that it is not the
> ATSC's fault.
>
> TTFN,
> Mark
>
>
>
> ----------------------------------------------------------------------
> 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.
>
>
----------------------------------------------------------------------
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: