[Theora-dev] A/V sync strategies

[Monty]

On Mon, Mar 14, 2005 at 05:47:12PM +0100, Ivan Popov wrote:
> Hello Keenan,
> 
> On Sat, Mar 05, 2005 at 08:32:57PM -0500, Keenan Pepper wrote:
> > Ivan Popov wrote:
> > >but I'd appreciate if you can give a run the theora-encoder script
> > >and see if it breaks in the same way (it shouldn't).
> > 
> > Sorry, but I ran the script using the example_encoder from theora svn 
> > and mplayer 1.0pre6, and the sync is off by a quarter of a second after 
> > a half hour. I'm fairly sure I have the correct framerate, because I 
> 
> oh! I have never seen that.

Mplayer, at least a year ago, does not mark or fill in dropped frames
in a raw frame dump.  I imagine it doesn't try very hard on sync
anywhere and raw frame/audio dumps have no timestamps (eg, any
encoding boundaries or deviation from strict sync in the raw output
will cause the reencoding to drift).  Forcing framerate does not alter
this behavior.

I don't know that this still happens today, so you may want to dump
the A/V to raw and playback the raw dumps to see if they stay in
sync. I'm going to guess they don't.

Second possibility: The player example was written for OSS, and OSS is
fairly buggy (that is, the decoder example was written taking these
bugs into account to work properly).  It's very common for OSS apps to
have sync problems with ALSA's OSS emulation because it doesn't
faithfully replicate all the bugs.

I don't know that either of the above provides an answer, but I hope
it was helpful.

> I do not know details about the original data stream.
> In a rational world, it should contain a couple of streams, each
> timestamped so that each of them can be played correctly alone.
> My experience is that it is usually the case.

Right; mplayer doesn't do this.

> Even then, the errors should not accumulate, I think.

They can and they do, especially on edit boundaries.  

Monty