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>