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

[Corey Hickey]

Rich Felker 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.

Ok, then. Fair enough, I'll do it.

>>>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.

Ok. I'll work it in.

>>>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?

The two in question are s->timer and s->buffer.

When the buffered frame is about to be sent to the muxer, I set
s->buffer to point to the memory I've saved the buffer in and s->timer
to equal the value it had when the frame was buffered.

This is made a bit more complex because both s->timer and s->buffer can
and do change between the time the most recent audio frame was buffered
and the time a video frame is sent to muxer_write_chunk(). I can't
assume that values in the last buffered frame for each stream are still
current.

The simplest way I see is to save s->timer and s->buffer in temporary
variables each time I'm about to put the stored values in.

-Corey