From owner-freebsd-multimedia  Mon Dec 22 10:26:30 1997
Return-Path: <owner-freebsd-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id KAA13346
          for multimedia-outgoing; Mon, 22 Dec 1997 10:26:30 -0800 (PST)
          (envelope-from owner-freebsd-multimedia)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA13340
          for <multimedia@FreeBSD.ORG>; Mon, 22 Dec 1997 10:26:28 -0800 (PST)
          (envelope-from hasty@rah.star-gate.com)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1])
          by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id KAA01545;
          Mon, 22 Dec 1997 10:26:01 -0800 (PST)
          (envelope-from hasty@rah.star-gate.com)
Message-Id: <199712221826.KAA01545@rah.star-gate.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Randall Hopper <rhh@ct.picker.com>
cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, multimedia@FreeBSD.ORG
Subject: Re: MPEG audio/video sync & Re: These mtv video pauses are murder 
In-reply-to: Your message of "Mon, 22 Dec 1997 13:10:21 EST."
             <19971222131021.09670@ct.picker.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 22 Dec 1997 10:26:01 -0800
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-freebsd-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


The PTS, Presentation Time Stamp, field is not going to help due to 
that your program is not doing the encoding .

The PTS field is useful when the program is creating the mpeg stream.

	Cheers,
	Amancio

> Luigi Rizzo:
>  |well my point was that the right (I would even say "the only") approach
>  |to get timing info in a video+audio steam is to use the audio sample
>  |clock. It makes life easier in the reproduction phase since it is much
>  |easier then to keep video in sync.
>  |
>  |Probably my previous posting was confused enough to obscure the above
>  |point.
> 
> Oh ok.  Now I see what you mean.  That's a good point.  Rather
> than clock to "realtime" and assume that the sound driver is going to
> faithfully record (& then play) 44.1KHz samples at "exactly" 44.1Khz.  Clock
> to the audio, so if the associated driver happens to record or play a
> little slower/faster, the video still stays in sync.
> 
> I'll browse around over the holidays and see what I can find out about MPEG
> audio/video sync options (the PTS field Pete mentioned, etc.).
> 
> Randall
>