[MPlayer-dev-eng] [PATCH] enable vobsub in mencoder
Dani Church
dani.church at gmail.com
Wed Sep 30 09:59:44 CEST 2009
On Wed, Sep 30, 2009 at 03:24, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> I assume this is a copy from mplayer.c.
> While some people would like to just let mencoder rot, I think this
> really needs to be made into a common function that mplayer and mencoder
> share, otherwise at least one of them will become broken rather soon.
It's mostly a copy, yes. The one in mplayer.c has a few additional
lines dealing with mplayer-specific functionality, though, and I'm not
at all familiar enough with the codebase to do any refactoring. This
was about a two-hour dive job, which I mainly did because apparently
this issue has been bouncing around the mplayer-users list since at
least 2004. If I were going to take a serious look into it, I'd
probably say that mplayer.c and mencoder.c should be about a tenth the
size they currently are, and should only deal with parsing and
validating command-line options. In fact, it would make a lot of
sense to me to turn it into a multi-call binary. After all, mplayer
and mencoder perform basically the same function: they demux and
decode one or more media files and then output one or more media
streams using various output methods. Why not allow mplayer to do
real-time encoding of a video/audio stream while playing it back for
the user? That'd be great when capturing from a video device, rather
than having to use some weird combination of -dumpstream and multiple
mplayer/mencoder processes. Why not allow mencoder to pop up a
thumbnail window that allows the user to see where in the video the
encoding process is? The only thing that's preventing these is that
the code for mplayer and mencoder are so divergent.
Sorry, I ramble. Anyway, yes, I agree, the code should be shared, but
the same can be said for a lot of the code in those two files.
-Dani
More information about the MPlayer-dev-eng
mailing list