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

[Rich Felker]

On Sun, Nov 06, 2005 at 08:49:50PM -0800, Corey Hickey wrote:
> Michael Niedermayer wrote:
> > whichever way its solved, not knowing the width/height when writing the header
> > is a serious problem independant of lavf, just think of nut where width/height
> > are variable length, so seeking back and filling it in wont work without some
> > hacks, and if i understand correctly we cant just write the header at the
> > first video frame as an audio frame might have been written before?
> 
> Last night I spent quite a while looking at how things work currently with
> mplayer's avi muxer and how the lavf avi muxer is different. I'm starting to
> get a basic understanding of what is going on.
> 
> mplayer's avi muxer writes the header twice -- once before it knows the video
> dimensions, and once at the end of encoding. If we can't wait until after the
> first video frame is decoded, then it seems like the best solution for the
> lavf muxer would be to write the header twice as well.
> 
> 
> Would the following plan be acceptable?

No.

> 1. Remove width/height sanity check from libavformat/utils.c, and let it write
> the header anyway.

This is strictly not allowed. Not only is it possible that the output
file is non-seekable (of course this may not work for all containers,
but for containers that do allow it, it must be supported); it's also
possible that rewriting the header once it's been written once is
inherently NOT POSSIBLE (without fully copying/rewriting the file from
scratch) due to order restrictions, variable size, etc. of the file
format.

> 2. Make the lavf muxer rewrite the header after encoding, just like the avi
> muxer does presently.

No, this is wrong for exactly the same reasons. Formats that need the
header rewritten after the stream is finished (for total length and
such nonsense) must use the "write trailer" function, but this cannot
be required for other (sane) formats.

[....]

> I wrote everything above before I read Rich's mail recommending that the
> packets be buffered; my idea wouldn't work for non-seekable output either.
> However, I think it could be an acceptable interim solution based on:

It's not because it requires BREAKING libavformat to make it work with
mencoder's brain damage.

> (a) There aren't any revolutionary changes.

...

> (b) The likilihood of breaking anything that works currently is low.

Except other apps that use lavf.

> (c) It's fairly simple and I could probably do it myself.

So is the buffering layer. It's just a matter of putting some
appropriate wrapper functions around the muxer implementation. Try it
-- it really won't be difficult!

> (d) There wouldn't be more to change if someone writes a buffer later.

Except reversing the evil hacks you propose to put in lavf!!

Rich