[MPlayer-dev-eng] MEncoder: libass support (patch)

[Nicolas George]

Le sextidi 16 brumaire, an CCXVI, Uoti Urpala a écrit :
> MEncoder is unmaintained and needs a major rewrite that nobody seems to
> be interested in doing at the moment. So don't expect much interest in
> minor MEncoder-related patches when its major problems would still
> remain.

That is quite sad.

Now that you mention it, I was wondering: what is the benefit of having two
different tools?

mplayer is all about decoding audio and video frames, passing them down a
filter chain, and to an output driver.

mencoder is all about decoding audio and video frames, passing them down a
filter chain, and to an encoder and muxer.

As far as I can see, mencoder is a special case of mplayer where the output
driver is an encoder and muxer.

Is there much in mencoder that is not already in mplayer? I can see the
-ofps handling, -vobsubout and -o[av]c copy, and a few small tuning options.

> I think the libass maintainer has little time at the moment. I'll see
> how ugly a full fix would be. According to the C standard the padding
> bytes may change value when values are stored to the struct (for example
> the compiler could fully write a register wider than the value stored,
> possibly with junk in the higher bytes) so zeroing the struct before use
> does not guarantee the padding bytes will be zeros.

You are right, of course.

Writing a proper fix require to write a glyph_compare function, which is
quite trivial, and a glyph_hash function, which may be less annoying that I
first thought. I will try to do something if I have time soon.

Do you happen to remember if it is guaranteed that memcmp is a valid
comparison for integers? For floats?

Regards,

-- 
  Nicolas George