>John M McIntosh wrote:
>
>I don't know enough of the inner workings of the mpeg format, but isn't
>there a common timecode reference to both streams so one can sync the up
>at any point ? It's more likely that video frame rate drops than
>audio sample rate so one could skip the number off frames it lags behind
>e.g.. now it skips 3 frames when it lags behind but shouldn't this
>number
>be calculated at every occurrence of out of sync so it's a perfect sync
>again ?
>
>Karl

Yes I need to calculate a proper skip number, versus clamping the 
value to 3. My original thought was to clamp so other activity which 
causes a sudden temporary  performance issue wouldn't cause a sudden 
bunch of frame skips, rather we would drop a fixed number of frames 
at a high rate in order to sync. But in looking at how other systems 
handle it, we do need to skip a bunch.

I'll issue some Smalltalk code updates later today (12+ hours).

But if you want to change things right now look at

MPEGPlayer >>decideToSkipAFrame: delta averageWait: aWaitTime stream: aStream
	delta abs > aWaitTime ifTrue:
		[external videoDropFrames: 3 stream: aStream].


In a situation where we aren't able to decode the frames fast enough 
then aWaitTime should be zero or close to zero. delta is a negative 
number which indicates how many milliseconds we are behind. Just 
change the code to skip frames based on the milliseconds need to 
resync and the frame Rate (self frameRate). millisecondsRequired/1000 
= 1/framerate*framesToDrop.


There is some other code lurking
calculateDelayToSoundGivenFrame: frame stream: aStream

where I attempted to sync the frame to the current sound sample being 
played however I found we can't really figure out which sample is 
currently being played there is too much buffering going on between 
the layers. One would need a VM call (I think) to get the required 
information. This tackles the problem from the other direction.



>but isn't
>there a common timecode reference to both streams so one can sync the up
at any point

I think so, but right now you know you are at frame 232402 out of 
5553222, and at 24 frames a sec you know which sample of sound you 
should be playing just based on doing some math. The trick is how to 
sync in Squeak. Right now we assume we start playing sound at time 
zero, and if we play 1 hour of sound data it takes one hour to play, 
but is this really really true? Anyone care to test?

-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================
Custom Macintosh programming & various Smalltalk dialects
PGP Key: DSS/Diff/46FC3BE6
Fingerprint=B22F 7D67 92B7 5D52 72D7  E94A EE69 2D21 46FC 3BE6
===========================================================================