[MEncoder-users] Timestamp on audio and video frames?

[Levente Novák]

On Mon, 2007-06-04 at 14:54 -0700, RC wrote:
> On Mon, 04 Jun 2007 10:05:32 +0200
> Levente Novák <lnovak at dragon.unideb.hu> wrote:
> 
> > (Or am I misunterstanding the nature of this problem?)
> 
> Very much so.  If the input video is out-of-sync, any timestamps
> Mencoder adds will be equally out-of-sync.
> 

But why? Is not timestamp the exact time when a frame was grabbed?

If MEncoder would add a timestamp to some or every video and audio
frames _independently_ (e.g. HH:MM:SS.SSS of the moment it captured
them, but separately for audio and video), I don't see how this could
lead to async. 

If you match the two timestamps you can then make them perfectly in sync
(eg. for a video lag, you drop some audio frames or duplicate some video
ones until the next audio timestamp matches the next video timestamp).
It wouldn't be a requirement to have a timestamp on all frames if this
is slowing too much the encoding, 1 per 100 or 1000 would be enough.

> Try playing the video with -mc 0/0.001/1/10, or use the various delay
> options to compensate for a fixed amount of desync.
> 

Let me explain the problem: the CPU load is at about 85-90% while
grabbing, with peaks at 100%. Therefore, the nominal 25 fps is not
always fulfilled, at moments it is only 24.9 or so. This is not much, it
is absolutely not noticeable when playing back. But as there are more
audio samples than video ones, after a long while, there is a desync
(video lag), but a non linear one.

What would help:

- a new CPU/mobo (out of question for now)
- a new capture card which is not as braindead as bt878 (I have to 
  capture in uyvy, deinterleave, scale, convert to yv12 and reinter-
  leave, just for have my chroma and luma lined up, since 4:2:0 is
  broken. It really is, the image is _much_ better this way compared to
  grabbing in yv12 colorspace). This is also out of question for now.
- adjust the drift manually. Very tricky, a the lag is neither fixed nor
  linear by nature: it depends on when and how the fps changes slightly.
- the ideal workaround would be to have timestamped audio and video
  frames (with independent timestamps), the muxer matching these with
  each other, discarding or duplicating some frames if needed (BTW what
  is MEncoder doing without -mc0 and -noskip specified in order to main-
  tain the sync?)
- a more primitive approach, that's what I will do if the issue does not
  resolve: capture by smaller chunks and sticking these together.

> If it's a gradual (increasing) desync, and -mc doesn't fix it, you
> really have to just start adjusting the -fps slightly to match-up audio
> and video.

Unfortunately this is not the case. Anyway, AFAIK -fps is not tunable
for raw DV, which accepts only a nominal 25 fps for PAL and 30000/1001
for NTSC (and maybe also 24 fps, but I am not sure).

Levente