Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Dec 1997 10:26:01 -0800
From:      Amancio Hasty <hasty@rah.star-gate.com>
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 
Message-ID:  <199712221826.KAA01545@rah.star-gate.com>
In-Reply-To: Your message of "Mon, 22 Dec 1997 13:10:21 EST." <19971222131021.09670@ct.picker.com> 

next in thread | previous in thread | raw e-mail | index | archive | help

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
> 





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712221826.KAA01545>