[MPlayer-advusers] [BUG] mencoder floating point exception with -of lavf

[Rich Felker]

On Wed, Nov 16, 2005 at 12:01:28AM -0800, Corey Hickey wrote:
> > bad: it has to buffer as much as needed. Buffers should be
> > realloc()ed and free()d as necessary
> 
> Isn't it necessary to impose some kind of a limit with regard to how many
> frames can be buffered? In the extreme case I'm imagining a hypothetical
> (though perhaps unrealistic) file that has a video stream defined in the
> header but actually has only audio frames. Without a limit, mencoder would
> just chew up memory until it ran out or reached EOF.

I think it's better to work in all valid cases, and allocate memory
without bounds until it runs out in invalid cases, then to exit with
error in some valid cases... Just my personal opinion though.

IMO the memory thrashing from realloc isn't a big deal. Under normal
circumstances it will only be a fraction of a second before the
buffering is finished, anyway.

> > 1) buffer as many frames as needed until you have at least one frame for
> > every muxer_stream
> 
> I can do this, but is it necessary to wait for the audio? I thought the
> characteristics of the audio to be encoded were known once
> preinit_audio_filters() is called.

Well it's probably a better/simpler design and wouldn't hurt. But I
don't really care.

> > 2) when you meet the above condition call muxer->fix_parameters() for
> > every muxer_stream and
> > muxer->write_header() the first time, then flush the buffered frames
> > calling muxer->write_chunk()
> > for every buffered frames in the same order as you stored them
> 
> That's pretty much how my patch does it. The only weirdness is that I have
> to temporarily alter some members of each muxer_stream_t when flushing the
> buffered frames. ...and make sure the data is back to its original state
> before muxer_write_chunk() returns.

Can you elaborate on why?

> >>-    s->timer=(double)s->h.dwLength*s->h.dwScale/s->h.dwRate;
> 
> > I would prefer to set s->timer incrementally rather than with a plain
> > assignment;
> 
> I'll look into that. It just occurred to me, though: wouldn't incrementing
> s->timer allow rounding errors to accumulate since it's a double? Just a
> thought; I'll investigate next time I'm at home.

I agree, your way is better. I fear rounding errors as well.. using
floating point at all in mplayer is stupid but it would take a huge
effort to fix everything. :)

Rich