Re: Audio synch issues with CBS HD

On Thu, 22 Sep 2005 19:53:20 -0700 hac <redacted@xxxxxxxxxxxx> wrote:
| On Thu, 22 Sep 2005 18:23:49 -0400, Smarty wrote:
|
|> Unfortunately, in the design of current digital TV systems, the audio
|> and video signals are independently compressed using two entirely
|> different methods, then mixed / muxed together with some time stamps to
|> allow the receiver to get things back into synch.
|>
|> This bifurcation of the data can and often is corrupted by DVD authoring
|> programs, retransmission of the signal by local broadcasters, and video
|> editing, compositing, or studio switching equipment. We are still
|> witnessing the infancy of the HDTV broadcast industry with a lot of
|> glitches and problems.
|>
| I've run into this while editing HDTV captures, and converting them to
| formats that will fit on a DVD-R (the largest storage format on my HTPC).
|
| Some software grabs the first time stamps, calculates the difference
| between the audio and video, and assumes that the delay will stay the
| same.
|
| That's a bad assumption. It may stay the same for a long period. But it
| may change at any time. Once the system starts ignoring the the incoming
| timestamps, then the timing is lost for everything downstream.

Actually there are two assumptions being made here. If the delay will
not be the same, then something is already wrong in the incoming A/V.
That could be a missing section of one or the other. That could be bad
software doing the original digitizing. But the big problem is, how do
you know whether a jump in timestamp difference is due to missing data
or due to miscalculated timestamps. Given no other means to syncronize,
one assumption or the other has to be made. You have to either assume
the timestamps themselves are the authority for syncronization, or you
have to assume the quantity (time length) is consistent. Either of these
assumptions could be inconsistent with what you get when dealing with any
possible software bugs in the environment creating that A/V content.

But I did say two assumptions are being made. In addition to assuming
how content is supposed to stay in sync, there is also the initial
assumption of how to get it in sync in the first place. If software
can be faulty and produce inconsistent timestamps for consistent length
material, then using the starting difference makes sense (until there is
some missing content). However, if software can result in some missing
content or otherwise unexplained timestamp shifts, then assuming that
the starting point itself is in sync isn't even valid.

Given a world where software developers so frequently do things wrong,
such as inocrrect timing calculations, or poor error handling that lets
physical errors corrupt data streams, no assumption can cover all the
possible problems.

And it doesn't help that audio sampling rates are not a whole number for
a single frame of video in so many cases (e.g. "NTSC legacy" frame rates
in North America). The methods to deal with that could be the cause of
"strange software".

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
.

Relevant Pages

  • Re: tmnsp.net???
    ... white video that was done by BHP in 2005. ... This portion of the audio was normalized to blend in better. ... missing that was filled by using graphics and audio source. ...
    (rec.music.gdead)
  • Re: The Dead started to go downhill after 72
    ... white video that was done by BHP in 2005. ... This portion of the audio was normalized to blend in better. ... missing that was filled by using graphics and audio source. ...
    (rec.music.gdead)
  • File archive of live streaming
    ... I want to know about how to archive the file of the live streaming of audio & video. ... I am taking the Timestamps from the video packet ...
    (microsoft.public.win32.programmer.directx.video)
  • Audio Video Synchronization in RTP streaming
    ... RTP packets.Both audio and video packets are timestamped. ... I am taking the Timestamps from the video packet ... I am taking the Timestamps from the video packet ...
    (microsoft.public.win32.programmer.directx.video)
  • Live Source Filter and Timestamping
    ... RTP stack, so I have timestamps for my audio and video from the RTP ...
    (microsoft.public.win32.programmer.directx.video)