[FFmpeg-devel] [PATCH] fix timestamps in vc1testenc

Reimar Döffinger Reimar.Doeffinger
Tue Dec 7 22:17:38 CET 2010


On Tue, Dec 07, 2010 at 10:09:31AM +0200, Kostya wrote:
> On Tue, Dec 07, 2010 at 08:21:28AM +0100, Reimar D?ffinger wrote:
> > On Tue, Dec 07, 2010 at 08:18:38AM +0100, Reimar D?ffinger wrote:
> > > Hello,
> > > this muxer currently when writing the timestamps does not take into
> > > account the stream time base, leading to completely "random" scaling
> > > of the frame time at least when using mencoder.
> > > Below patch rescales the pts values like other muxers do.
> > 
> > Note that I think the demuxer is broken, too.
> > It does av_set_pts_info on the fps value in the header, but like
> > for WMV that value is just a kind of average, and rounded to
> > full FPS on top, it really should only set r_frame_rate and always
> > got by pts.
> > However I do not know if there are any (particularly the official test
> > streams) where this might cause an issue.
> 
> The spec says that if you gor FPS value value != escape (0xFFFF IIRC)
> then it should use constant frame rate otherwise it's VFR with time_base
> 1000.

Yes, you know it is constant frame rate. Which doesn't help you one bit
since you do _not_ have the frame rate. The value in the field is only
the _rounded_ FPS. So you still need to go by the pts in order to play
it correctly.

> And I wonder why all muxers should rescale PTS.

Because the alternative is to have a way for the muxer and whatever does
the rescaling having to negotiate the time base, which sounds like a
huge pain.
I guess you could have a flag indicating if the muxer supports arbitrary
per-stream timebases but it would still be less flexibilty without saving
much code (or even ending up moving it into the application, which IMO
is worse than duplicating it in the muxers).



More information about the ffmpeg-devel mailing list