Re: DTV audio / vidio sync
- From: phil-news-nospam@xxxxxxxx
- Date: 29 Jun 2006 04:20:15 GMT
On Thu, 29 Jun 2006 01:05:03 +0200 Tadeusz Krzeminski <krzemien@xxxxxxx> wrote:
| On 28.6.2006 23:56, in article e7utuq0gcl@xxxxxxxxxxxxxxxxx,
| "phil-news-nospam@xxxxxxxx" <phil-news-nospam@xxxxxxxx> wrote:
|
| [cut]
|
| All that you have written in your response is true.
|
|> Ultimately, there is no real need to separate the audio and video paths when
|> dealing with digital. A "best design" protocol/format would have each slice
|> or chunk of the stream consist of all audio channels and all video for that
|> time slice together in the same chunk, along with any anscillary info such
|> as captioning. I believe SDI actually does this (but the documents I have
|> found so far are not detailed enough to be 100% sure).
|
| And that's true as well. In modern broadcast facility all timing is (or
| should be) carefully maintained. At the end (emission desk) you've got to
| deal with SDI-Audio Embedded and that should be time-error resilient.
|
| But - unfortunately - please do not forget about all the 'side chain'
| equipment: logo inserters, audio processors etc.. Engineers like to play
| with that toys and they easily forget about uneven consequences...
If you're talking about some kind of processor that takes SDI in and puts
SDI out, than that equipment itself is responsible for making sure things
stay in sync. Aside from a piece of equipment specifically intended to
make delay adjustments differentially, any delay of some part of the A/V
content introduced by the process it is performing should take all the
other parts along for the delay. A logo inserter that has programmed
still logos should be able to insert them with relatively little delay.
But inherintly, there will be some delay because frames of bits still have
to be collected and processed as a group. Other kinds of processors could
potentially have 2 or even more frames worth of delay (especially if
processing video where often the entire frame has to be collected before
outputting the result frame can even begin, such as reducing HD to SD with
letter boxing). The engineers have to have some degree of control over
these delays to make sure all their sources come together with consistent
timing to the final master control switcher. But these days, even big
delays here can be tolerated ... you just get a continuity jump if the
switching was between related contents (more of an issue in production
switching than in master control). Modern equipment will maintain frame
syncronization. But the big point is, properly designed equipment will
delay the audio and video the same, where it came in together, such as via
SDI. But there is still equipment around that does not ensure things stay
in sync (e.g. Pathfire), and quite likely because it is dealing with audio
and video in separate ways without any timestamping to ensure they are
back in sync when output.
Ever hear of VHS or Betamax every getting A/V out of sync? But things
like DVD do so often, and generally not even reproducible. When there are
"buffer loops" ("ring buffers" in programming terminology) that are
separate for audio and video, the exposure to even the slightest error
exists wherein the buffer can "wrap around" incorrectly and either drop or
duplicate a chunk of data. If something happens that causes the source
data to become unavailable, in theory the buffer can "drain down" to the
point it is just about empty. If the source suddenly has data available,
the buffer just saved the sync. But badly designed buffers will just loop
back around and play the old buffer contents all over again and you hear a
machine gun or slower repeating effect for audio, and video often just
freezes on a frame or two. If this buffer is handling interleaved A/V, at
least the effect is in sync and when the data source works again, the
content remains in sync. But if you have separate buffers (e.g. the
different paths design), you could end up with one of them taking a single
extra loop around, and not the other, and now lose sync.
While I am sure there are many cases where station personel are at fault
for some of the sync problems seen on the air, my background in computer
programming (34 years of it) and basic knowledge of some hardware (writing
some drivers) ... and most importantly: seeing the enormous number of
programming and design errors by my "colleagues", I will generally first
point the finger at the equipment and the engineers and programmers that
designed it AND the managers that set unrealistically short deadlines, and
hired insufficient staff to get the work done right. Next I will point
the finger to station managers for choosing equipment entirely based on
price and ignoring quality. That's not to say they have the financial
resources to do any different, but this is where the blame too often is.
But be prepared to point the finger at your ATSC receiver, too.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-06-28-2233@xxxxxxxx |
|------------------------------------/-------------------------------------|
.
- References:
- DTV audio / vidio sync
- From: DanR
- Re: DTV audio / vidio sync
- From: Tadeusz Krzeminski
- Re: DTV audio / vidio sync
- From: Mike Potratz
- Re: DTV audio / vidio sync
- From: phil-news-nospam
- Re: DTV audio / vidio sync
- From: Tadeusz Krzeminski
- DTV audio / vidio sync
- Prev by Date: Re: DTV audio / vidio sync
- Next by Date: Magni WV561 - 75% ColBar
- Previous by thread: Re: DTV audio / vidio sync
- Next by thread: 20 yearold Sony KV-25XBR
- Index(es):
Relevant Pages
|
