[MPlayer-dev-eng] [PATCH] -vobsub support for mencoder

[Uoti Urpala]

On Wed, 2010-02-10 at 14:57 -0500, compn wrote:
> On Wed, 10 Feb 2010 17:37:08 +0100, Gianluigi Tiesi wrote:
> >On Wed, Feb 10, 2010 at 06:43:13AM +0200, Uoti Urpala wrote:
> >> If you really need more functionality then a more sound approach is to
> >> add the encoding functionality you need to MPlayer (start from MPlayer
> >> with vo yuv4mpeg and add the encoding functionality you need, instead of
> >> starting from MEncoder and trying to fix it).
> >> 
> >
> >you cannot encode faster than realtime this way, or I'm wrong?
> 
> you are wrong, it should work about the same way as -ao pcm -benchmark

-nosound or -ao pcm:fast

Sure the encoding functionality you get with that is limited; but adding
more is a better idea than trying to add the missing playback and other
features to MEncoder.

> but are we sure that starting over and adding a bunch of code to mplayer
> is the right way to do it ? if we are to drop mencoder, why not just
> focus on getting binary codec support into ffmpeg?

I'm not sure whether trying to keep any encoding functionality in the
MPlayer codebase is a good goal or not long-term. Currently I guess the
biggest things missing from other programs are binary codec support and
some filtering functionality. Adding enough functionality to allow
exporting decoded/filtered video for further processing in other
programs would be realistically doable without huge amounts of work.
Maybe libavfilter will remove some of the filtering uses, though it's
hard to be sure yet.

> and if mencoder is unmaintained and no one cares about it, then i say
> apply these patches forthwith! end end these endless discussions about
> killing mencoder. lets see you rm -rf it in git first!

I wonder if you maybe misunderstood my main objection to such changes.
Trying to make MPlayer and MEncoder share more code without a massive
cleanup of MEncoder is a bad idea because it ties MPlayer more closely
to the unmaintained MEncoder. Sharing code is bad in this case because
it means changing the code then either breaks MEncoder or requires
altering it (making such changes harder). Even changes that could be
described as "reducing code duplication", which is usually a positive
thing, are bad when one side is a mess (and bad enough that such changes
aren't really even a small step towards fixing it). MEncoder is a mess,
and would require much more than such changes to stop being a mess. As
long as the codebase is as separate as possible it's at least a mess
that can be mostly ignored when working on anything else.