[XviD-devel] [BUG] Segfault with large fincr/fbase values

[Christoph Lampert]

On Wed, 14 Jul 2004, Adam Thayer wrote:
> On Jul 14, 2004, at 12:27 AM, Christoph Lampert wrote:
> 
> > Btw, your values should be swapped, right? fbase is supposed to be 
> > larger
> > than fincr, because fps = fbase/fincr.
> 
> Well, either direction, XviD produced valid data with the right 
> framerate. Since there wasn't enough documentation on how the frame 
> rate fractional was supposed to be represented in either ffmpeg or XviD 
> (without delving beyond headers), I went with ffmpeg's layout where fps 
> = frame_rate/frame_rate_base. It produced an MP4 file that would be 
> noticed with the proper frame rate. Although your method does the same. 
> In this situation, a file setup so that fps = fbase/fincr causes 
> mpeg4ip's tools to crash, while fps = fincr/fbase results in files 
> mpeg4ip's tools read just fine. Curious.

In the standard (section 6.3.3?) they are called, 

vop_time_increment_resolution which is an unsigned 16bit integer, 
specifying the number of "ticks" per seconds,

and 

fixed_vop_time_increment taking values between 0 and 
vop_time_increment_resolution (not included), and which is the number of 
"ticks" per frame. 

In XviD fbase should be vop_time_increment_resolution and fincr should be 
fixed_vop_time_increment, because that's how I planned it to be, 
and also it wouldn't be logical any other way. This also seems to be the 
case, since the default is  fincr=1, fbase=25  (encoder.c)

I don't know the ffmpeg method, but if you see it in XviD done anywhere in 
any other way, please send us a bugreport or even better, directly a 
patch. 

chl